Bridge plug-in runtime error.

[christ23]

Dear bokkie,

sorry that i sometimes do not react in the same minute. This is due to me being on holiday

But sometimes, i have in mind that i have to drive the plugins.

First of all, i will answer one of your questions :

Christ23: When you were using MaxLogic's bridge, did they (a) work for you without plugin discovery problems, (b) did you do anything in the CompileTimeBuild method, and (c) did you have to perform any additional magic like pulling rabbits out of a hat?

(a) Yes, the plugin has been located and "plugged-in". This means, i could drop it into IA / type into IA the represent i defined in the plugin-registry (wrote an excerpt of that to you already). The Plugin is called at design-time AND at runtime (the last one, after some frickeling around with $SUPPORTDIR$.

(b) Yes, in the compile-time method i am copying ALL needed files (as MaxLogic described) into the $BUILDPATH$-Directory

(c) No

But, my plugin - first only running in IAs debug-mode and later being called by "normal duble-click starting the .msi, but the throwing the "is not a valid integer value (see my other post) is still crashing. Seems i am just ONE step away from getting the plugin working.

So, i will wait for Francesco's experience, too. I spent over and over of time into developing a plugin, but now i am quite a bit disappointed, because every problem i solve causes another new one, or one that seemed to be eliminated.

[FrancescoT]

please be patient ... ( actually .... I'm going crazy).

[christ23]

Ok ok, we will be patient .

Do not hurry - i believe you will do the trick for us all. I am looking forward

[bokkie]

I've been trying a couple of things I've not done before. It didn't change the outcome of the "Unable to load plug-in library" message but this is what I've added to my project stuff:

1. Inside the CompileTimeBuild method I displayed the parameters. The msihandle was a positive integer; the buildpath had a pathname; the build boolean was true; and the fetch boolean was false.

2. I created the buildpath and I copied the 2 x bridge dlls, 2 x bridge ini files, and the 2 x dotnet dlls into it. Successful.

3. I also created the runtime bridge folder in the buildpath parent folder and copied the same files in (2) into it.

4. I removed all my support files and added them again and this time, I added them using the files in the buildpath. Not 100% safe but I know the files did exist. That is, I didn't delete the Release folder.

As you can see, I'm trying variations but with no overall progress.

[glenharvy]

Hi bokkie,

1. No one has been able to get this to work. (christ23 has been trying for many months - not the last couple of days).
2. The samples are based on what someone else has specifically designed - ie the mEXEPlug.dpr and mIDEPlug.dpr . What are .dpr files and what's in them I don't know.
3. IA have never actually used and therefor even tested this 'bridge' despite all the advertising indicating this function as a great new feature.
4. The experts at IA have experienced the same problems that we have and are trying with the aid of the original author to get this 'bridge' working - so far without any luck.

I don't think this is going to work no matter what combination of options you try. Something is broken and only the author can fix this. IA and ourselves are in his hands. Not a good position that IA has got itself into if you ask me.

Frustrating isn't it.

[bokkie]

Glen,

1. I only began to understand the importance of CompileTimeBuild for the first time yesterday or the day before. I thought that if I did the copying as recommended that I might get a bit further. When christ23 ran into his problems I again thought they were relatively recent and that his "integer" problem occurred not because his plugin didn't run at runtime, but because it ran and then failed. I didn't recognise that his problems had been going on for a good deal of time. That sort of made him a pioneer.

2. I believe that .dpr files are Delphi project files, one of two languages (C++ is t'other) that natively support plugins.

3. I think I also understand that IA was developed in Delphi which possibly explains why the original bridge came with Delphi-based samples like you identified. It was perhaps regrettable (although understandable) that the bridge was publicly heralded as a feature of NX. Perhaps the good folks at IA trusted it, like us, as good to go. If it can be fixed then it could cause a revolution (in relative terms) of what plugins can do. I have some specific ideas that will really help here at work. It's do-able without plugins but a plugin would be more flexible and reusable.

4. I really appreciate what's going on behind the curtain. I've no idea what the guys at IA, Francesco, Pawel (MaxLogic) and anyone else is doing as I know no more than you. I hope it can all be fixed and if they can offer something you, me, christ23 and no doubt some others will be more than ready to beta-test and use it.

[FrancescoT]

Dear Guys,

I apologize with all of you if I can seem hermetic, but that's only because I'm really involved in many activities and very often do not have time to respond adequately. But I can assure all you that I am personally committed to solve this problem.

As Bokkie said and as I already done with one of my previous reply, the CompileTimeBuild function is the core of the correct placement of plugin files and not less important, the correct IA engine fuctionality during runtime execution. To better understand how it really works, as I already said, think at this function as FILE BAG plugin does when storing files.

It is exactly the same technique and actually, seems to be the cause of the Net Bridge runtime issue, I really thing is just a question of time to have this definitively solved. As all you of you know ( ... we all developers), sometimes you spend nights and days (and headaches) to solve a problem.

Believe me, I'm really counting out the time to finally say to all of you .... "DONE! It works!

To be continued ....

[bokkie]

We understand, Francesco. We'll be ready and waiting...

Developers get headaches? Not always. When I was younger I used to work much longer hours. Not because I had a headache but because my wife did, if you understand what I mean?

[christ23]

Bokkie and glen, i am according to you. Hm, i am a pioneer ? No, i only want the plugins work .

I am also a bit disappointed about IA giving out tools with a new NX-Version withiot having tested it durable. That would be me lawt day if i did a process like this kn my job . But this shall not criticize the IA people, sometimes things just get missed.

So we will continue waiting, and of course, i would happyly test the beta version.

To be continued ...

[bokkie]

Francesco,

No pressure, honestly, but do you have any feedback you can give us how things are going with this?

[FrancescoT]

Dear Bokkie,

Found the cause ...and we are preparing the fix.

So really, it is only a matter of time required to prepare it and some additional tests.
As you know, this kind of work sometimes requires time



Regards

[bokkie]

If you'd like some of us to test it before you tell the world I'm more than willing to do so. For obvious reasons, I won't publish my email address here but if you ask Jason Strathmore at IA he'll be able to give you my address if you want to use someone as beta tester for the plugin stuff. Let me know.

[christ23]

Dear Francesco,

nice to hear these news. Great fine !
According to bokkie, i am willing to do some beta tests if you need some .

So let us know when you are finished. Do not hurry too much - only produces mistakes .

Greetings !

[glenharvy]

Found the cause ...and we are preparing the fix.

Ok, hopefully that fixes the background processing but just as importantly (at least to me) is the IA Graphic User Interface. So far there doesn't seem to be one although I suspect the original requester of this excellent plug-in has designed one. I say requester because the plug-in itself doesn't seem to come with it's own IA GUI.

The Run DLL Plug-in supplied by IA is an excellent example and I am wondering if it is supposed to be the actual method of interfacing with the C# Bridge.



Presumably we will insert the path to the dll as referencing the bridge.dll and the bridge.dll in turn requests the c#.dll.

Or is this all wishful thinking on my part

[MaxLogic.eu]

2. After the build, I took a look in the Release -> Uncompressed -> data -> OFFLINE folder. There is only one folder DesignTime_NetBridge.dll and it's empty.
This seems to suggest to me there is something missing?

Yes there is something missing. But the files your are looking for will not be copied by the net bridge. you must do this yourself in your compile time net assembly.
especialy, the runtime net bridge dll and its ini file.

The functions which must be exported by the design time DLL and their expected behavior is described below.

CompileTimeBuild

This function is called when the project is being compiled. The function should copy the necessary files for its operation, modify the Windows Installer database if necessary, and indicate whether it will require access to setup files during installation.

(...)

BuildPath
The full path to the folder where the plug-in must copy its build files to. At a minimum, the plug-in should copy its Run-Time DLL to this build location. The plug-in may also copy other files as needed (for instance, if the plug-in installs any files, it should also copy those files).

You need to copy at least 3 files:
1. runtime net bridge dll
2. runtime net bridge ini file
3. your net assembly

In C++during Project build time the IDE plugin DLL is called by the function "CompileTimeBuild". With this function the IDE plugin is responsable to perform all the required file copy operations. So the plugin must physically copy all the required runtime dlls by to the directory pointed by the "BuildPath" paramenter of the function.

The same is true for the net assembly plug-in. it is not done automaticaly by the compile time bridge dll.

I tried adding the bridge dlls, ini files, etc (see screenshot) but nothing changed.
I'm still left with an empty folder in the Release build. I've tried copying foldes containing the files into the "right" place but it doesn't change anything. A little later, I'll 7z what I'm working with and I'll post it here for someone else to eyeball. It's really frustrating!
It brings me back to Francesco's comment about having to copy files in the CompileTimeBuild method. Has anyone actually done that? Right now, I'm relying on creating the folders myself after I've produced the output media but is that actually the right thing to do? I mean, I'm doing something after the build that IA didn't know about beforehand.

You must do it in your net assembly code. I'm not sure if it will work if you add the net bridge somewhere else. IA might not be able to find it afterwards, as it is not present in the expected directory.

As far as I can decipher, there is no sample IDE Plug-in written in C# that includes the file copying function mentioned.

You are correct.
I wrote delphi for net samples, and a C# runtime sample.
The delphi samples were there to show that it is working, the C# sample was there to show that the progress callback can be called out of the net assembly in C# as well.
But the samples were not written with end users in mind. Not as a kind of a tutorial. All this was targeted at experienced developers, at my customer at IA. I see that this is causing some missunderstandings.

Good morning, Pawel. Thank you for looking at this thread and the problems some of us are having. If you scroll up a few replies you'll see a zip file I attached. If you have VS available would you be able to download my example and see if there is anything obviously wrong with what I have tried?

At first, sory for my late joining. But I'm not watching this forum. I just subscribed to some of the topics and am looking inside only if I got an emali notification.

But, my plugin - first only running in IAs debug-mode and later being called by "normal duble-click starting the .msi, but the throwing the "is not a valid integer value (see my other post) is still crashing. Seems i am just ONE step away from getting the plugin working.

Francesco and I have found an issue and fixed it. More about below, Please try it out and drop me an email if you still have problems.





One problem I found using C# is, that the fetch parameter was not send properly back.
I think this is a com think as the net bridge uses it to gein access to the net stuff.
With my delphi for net plugin it worked fine. To make it work with C# as well we will have to change the declaration of the function a bit, it should look now like this:

Code: Select all

public bool CompileTimeBuild(Int32 MSIHandle, string State, string BuildPath, bool Build, ref string  Fetch)


then use just "true" or "1" for the true value. Case insensitive. any other value will be handled as false.
When using the net bridge, you always need to set it to true.


There was also a problem with the status text in the compile time C# code.

Code: Select all

- string TEST_STRING = "InstallAware\n2012";


That string is used in the code to set the new state parameter, as:

Code: Select all

//set the TEST_STRING in the buffer
NewState = TEST_STRING;


The carriage return char '\n' can't be used with plugin parameters.
For that there is an appropriate VARIABLE with IA called "NEWLINE".
This causes a serius error with IA engine that have as conseguence, that the BRIDGE EXE DLL is not correctly loaded by IA ( ...with the error "Plugin library not found".)

Francesco is testing and reviewing the fix. I send him my C# samples as well. As soon as he confirms that anything is fine now, he will upload the new dlls and the samples. Maybe a tutorial, Francesco ?

Ok, hopefully that fixes the background processing but just as importantly (at least to me) is the IA Graphic User Interface. So far there doesn't seem to be one although I suspect the original requester of this excellent plug-in has designed one. I say requester because the plug-in itself doesn't seem to come with it's own IA GUI.

The Run DLL Plug-in supplied by IA is an excellent example and I am wondering if it is supposed to be the actual method of interfacing with the C# Bridge.

Presumably we will insert the path to the dll as referencing the bridge.dll and the bridge.dll in turn requests the c#.dll.

The net bridge is only a bridge between IA and its C# compile time and runtime plugins.
It is only an extension of the IA plug-in architecture, allowing for C# plug-ins.
It is not a bridge between IA and any C# dll.
Keeping that in mind, unfortunately, you are the one to write the GUI part for your plug-in.




ps.: I see my forum subscription is not working... I got no info about any replies... strange... I will look from time if there are new posts, but in any case, drop me an email if something is going on.