Handling different versions of a referenced exe

S

sjn78

Junior Contributor
Joined
May 4, 2003
Messages
255
Location
Australia
I started running into problems at work when I wrote a program which references to another piece of commercial software...I will it call ProgramX. The problem is that we have about 4 different versions of ProgramX, so of course when I compile the program I wrote which references the latest version of ProgramX, it works fine on my machine. But when someone else tries to run my program and has an older version of ProgramX, my program will throw an error and stop working. I also tried compiling it using an old version of ProgramX, but it seems like you can only run my program on a machine with the same version of ProgramX as it was compiled on.

ProgramX is always installed to the same path, same file name, same everything. Not much changes between versions, just some new added features which doesn't alter the internal workings of it.

Is there a way to get .Net code to ignore this versioning problem and allow my program to run properly? I am accessing ProgramX via COM and work won't upgrade ProgramX to all the same versions. There is too much cost involved in doing this and only the people who use it regulary get the new versions.

Steve
 
hi Steve,

Have you considered a different approach? And if you don't mind, may I reply with a few more questions?
1. What exactly from programX does your program need? I mean, will your program use functions from programX or just the results? If what you need is the data from programX, maybe you can bypass programX entirely and go straight to the datasource. This of course is if programX is not some logging application.
2. Who owns programX? by the way your post is constructed, I am leaning towards the possiblity that programX is from a vendor outside your company? If so, maybe you can coordinate with this vendor?
 
Its software to perform mapping, GIS to be specific. I should of explained about the exteranl software a bit more. The software is called MapInfo, most people wouldn't know about it unless in the GIS industry.

The reason why I am using it in my program is to allow a customised interface and tools. When you load MapInfo into your application, it creates an instance of the software but runs silently in the background on your pc - you can see it running in the processess list. Therefore you are pretty much taking MapInfo and embedding it into your own application and have full access to its functionality. I build the gui side of things that will give better access to any viewers/tools/editors.

They are a worldwide company and they won't change it just for 1 person developing on top of their software in this way. That is why they allow you to embed their program and utilise it this way, so you can alter it, make it perform differently or add your own custom tools.
 
This is from JIT debugger. I compiled it at home last night using an earlier version than I have at work, so don't want to recompile it here...generally you would assume backward compatibilty.

************** Exception Text **************
System.Runtime.InteropServices.COMException (0x80040154): Retrieving the COM class factory for component with CLSID {BA2638EB-CB99-4908-9915-771E04BBB7D3} failed due to the following error: 80040154.
at Test.Forms.frmMain.frmMain_Load(Object sender, EventArgs e) in C:\Users\*********\Forms\frmMain.cs:line 30
at System.Windows.Forms.Form.OnLoad(EventArgs e)
at System.Windows.Forms.Form.OnCreateControl()
at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
at System.Windows.Forms.Control.CreateControl()
at System.Windows.Forms.Control.WmShowWindow(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
at System.Windows.Forms.ContainerControl.WndProc(Message& m)
at System.Windows.Forms.Form.WmShowWindow(Message& m)
at System.Windows.Forms.Form.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


In the bin folder, it creates a file Interop.MapInfo.dll. I am guessing this is specific to the installed version of MapInfo on the machine it is being compiled on. When I reference the exe, I tried changing the CopyLocal option to false, but my program crashes then.

The line 30 the error is referring to is where I create a new object for MapInfo so I can start using it in my program.
 
sounds like a 64bit app trying to call a 32bit DLL to me. Is your project's build property set to "Any CPU"? Try setting a build to X86.
 
my last post was based on the assumption that the DLL you are calling was properly registered (by running "regsvr32 MapInfo.dll" in the system32-folder) and resides in the correct folder because I saw Interop.MapInfo.dll.
You might also want to check the way the DLL is referenced. It might as well be a "file not found" error.
 
I don't have VS installed at work, so will have to test it out tonight. Its built using .Net 2, 32 bit and I think set for Any CPU.

I still think its something to do with the version of MapInfo on the machine as when I compile my exact same code on machines with different versions of MapInfo, it will work fine.

Just a thought, because it makes the interop dll when you compile it would a way around it be able to see what version of MapInfo is running, if the interop file is missing or a different version to whats already there, re-create the interop file to match the current version of MapInfo on the machine. I read somewhere that you can do this pretty easily.

I only say this because I could compile my code right now and it would work. So this would create the interop file for the newer version of MapInfo and everything will be happy
 
That's too bad mate. We will have to wait 12 hours before we can talk again.

Well anyways other things you might want to consider are:
1. The dll should be registered in the the correct path from the correct path.
2. This can also be an AuthorizationManager issue.
 
Is there any way to identify which version of the software is installed on a particular machine? If so you could potentially ship the interop libraries for all versions any use reflection to instantiate classes from the correct version at runtime.
 
I thought about that as well, maybe as a last resort. The program has an associated dll with the verion number in the filename. But I would have to compile the program on several machines with the different versions...which dont have ide's installed on them.

I was mucking around with trying to compile from command prompt since you dont need any sort of ide installed, but didn't get too far as I couldn't find the right arguement/parameter to indicate I am using a com library.

Also looked into using tblimp.exe to create the interop dll but all the examples I have found on the net, won't work. I thought if I could get the program to look for the interop dll and see what version it is and if its not correct, make a new one. But seems like it only comes with vis studio. Not sure if it is Vista, but I get that annoying program has stopped working dialog, which gives no information at all.
 
You should be able to use tlbimp.exe to create the interop dlls without requiring the full visual studio ide, these interop dlls can then just be copied to the development machine and built into your deployment package.
 
Think I have it all working now. The tlbimp.exe that comes with Express 08 didnt want to work for me, so I installed Express 05 and used that version of it...same command and the 2005 version works where the 2008 doesn't. Maybe the 2008 version is targeted at .Net 3.5, which you think would of worked at home because I installed the 3.5 framework when I installed Express.
 
Back
Top