Not able to load Ivi.configserver.interop.dll v1.6.0.0 via the policy.1.0.Ivi.ConfigServer.Interop.dll" in .NET ?

Hello Laurent,

I did a quick test and was able to create a very simple application using VS2005 on a machine with IVI Shared Components 1.4 installed. I built it in both 32-bit and 64-bit platforms and both ran on a Win7 64-bit machine with the latest IVI Shared Components (without rebuilding the app, of course).

Could it be that when you added the reference to your application you added it using the .NET tab instead of the COM tab? The source project file should have a <COMReference> in it rather than a <Reference>. When building .NET apps against COM components (as the Config Server is), it's important to use the COM tab for adding these references.

Also, if you do have direct references to the interop assembly, you could try using a config file for your app itself. Just put the appropriate binding redirect statements in your own config file and see if that works. These redirect are identical to what the IVI policy files would do. These redirects can also be added to the machine.config file in order to upgrade all apps on the entire machine at runtime.

Hope this helps.

Hello Kirk,

Thank you for your answer.

All instruments drivers are build with references added in COM components.

I already tested successfully app.exe.config and machine.config by adding data in runtime section in order to redirect assembly to the right release.

In our case, I think it is not the best way because out test Platform will be installed in several factories of our group and it is more appropriate to use the publisher policy provided by IVI foundation. On my previous post, I notice that the policiy files are missing for CPU x86 and AMD64. Who is able to generate or provide me this files, probaly IVI foundation ? Or does it exist another reason for the absence of these files ?

Laurent

Thanks for that feedback. The thing is, however, that for the small test I've done, the Any CPU policy file is picked up by the runtime when I run an x86 or x64 application built against 1.0.0.0 of the IVI Config Server. Write a simple C# application that just loads the config server and then prints the master location or something. Compile that application as x86 and also x64. Do this on a system with IVI 1.4 installed. Then, take that compiled application and run it on a system with the very latest IVI Shared Components. That works for me and using fuslogvw.exe indicates that the policy file was, indeed, found.

Hi Laurent,

I just wanted to check in to see if you had a chance to perform the simple experiement I mentioned. I'm working right now with the IVI Shared Components working group (of which I am the Chairman) and we are getting ready to release IVI Shared Components 2.3. But, we want to see if we have a real issue to deal with based on your experience, so we would like to resolve this particular issue with your assistance.

Thanks very much in advance.

Hi Kirk,

I implemented successfully the solution that you suggested, I also tested my issue by setting machine.config or by adding an app.exe.config. However that can not be the optimal solution because in our group, a lot of engineer in different business area developps test module or instrument drivers for our test Platform. Our main target is to move to OS 7 64bits but also to upgrade some components of the Platform ( eg.: Move from IVI1.4 to the last release (currently 2.2.1), Visual Studio 2013, TestStand2014, ...). For the future situation, all new developpement will be developed with the new components and new instrument drivers will be referenced to the Ivi.confserver.interrop 1.6.0.0. but also, the new test Platform must be able to manage the current test modules and instruments drivers (referenced to Ivi.ConfigServer.interop 1.0.0.0). Our plant manages almost 1300 references of customer products and it is the same ratio in the other plant. For my side and in order to have a robust solution, we need to have a publisher policy provided by Ivi foundation which is able to redirect 1.0.0.0 to 1.6.0.0. for all CPU.

Of course I'm ready to collaborate with you for this issue.

Hi Laurent,

Sorry for not being clear. My suggestion was to perform the experiment with a simple C# application and NOT a machine.config or app.config file. When I do that, I see the Any CPU policy file getting loaded and upgrading the console application. If the policy file was not working, then the C# application (originally compiled against 1.0.0.0) would not work when run on a machine with only 1.6.0.0. For me, it does work without changing anything. I'd like to understand if such a C# test application works for you (again, with no machine.config or app.config files in the process).

Hi Kirk,

I send you 2 logs from Fuslogvw.exe :

- First is for the simple C# application --> it works well --> see the first sheet on attached file.

- The second is issue from our testatform when the application attempts to load the instrument driver --> see the second sheet on attached file.

log ivi.configserver.interop.pdf

Ok, interesting. It's getting something from your machine.config file, though, so make sure you're not trying to do anything there. Then, modify your C# application so that it references the driver directly and just calls Initialize or something. What kind of driver is it?

• I posted a JPG file in order to show you that no redirection is set for Ivi.ConfigServer.Interop. (net framework 2.0 configuration.jpg)
• Application works fine when I reference the driver directly.
• Our drivers are com object and they are referenced to our test Platform. Each driver should referenced Ivi.ConfigServer.Interop in order to implement ExtraRegistration method.

Hi Laurent,

I'm sorry but I'm still a bit confused. If the simple application works when loading the IVI driver, then re-direction must be working in general. There's something different about your test platform. Maybe you're doing something like hosting the CLR yourself?

Hi Kirk,

What do you mean by hosting the CLR yourself ?

In the log file I sent yesterday, we got this error message: "ERR: An assembly with different processor architecture is already loaded". That means the ConfigServer is already loaded with another processor architecture (probably 'Legacy'). I checked the properties of our C# project of the test Platform and Instrument drivers. Both targets an "Any CPU" architecture.

Specialized applications can actually bootstrap the CLR (.NET runtime themselves), in order to have an isolated context for running .NET applications. SQL Server does this, for instance, in order to run .NET stored procedures. It's a pretty advanced and specialized scenario, so I just wanted to make sure none of that was in play.

I saw that error message in your log file, but don't have an explanation for why that behavior would be different from a simple C# console application. There must be something different about how your product application loads and how the simple test application loads.

Hello Laurent -

I have been in communication with Kirk about this issue. While we are puzzled that the simple C# application succeeds and your application fails, we agree it is odd that the Processor Architecture filed for policy.1.0.Ivi.ConfigServer.Interop is blank (per the image you posted). We will generate some policy files with the Processor Architecture field properly set for you to test with to see if this fixes the issue. I plan to post those early next week.

Laurent -

I am also curious - does your test sequencer use C++/CLI to call any of the Interop assemblies (driver or config store)? You mention TestStand 2014 one of your posts. Is your VS2005-based sequencer an earlier version of TestStand?

Hello David,

Our test Platform is able to run with a managed or unmanaged test sequencer. Currently, we are using TestStand4.1 (.NET 2.0), now we plan to move to TS2014 (.NET 4.0). I know, we have a low probability to connect the test Platform to an unmanaged test sequencer but we would like to keep this feature.

Please let me know when you'll have generate the policicy files for the other CPU architectures.

Hello Laurent -

The attached .zip file includes two pairs of publisher policy DLLs and config files, one for each x86 and AMD64. Can you use gacutil /i to install them to your GAC and let us know if installing them fixes the issue? Could you please let us know which of the two (x86 or AMD64) fixes the issue?ivi.configserver.interop_policyfiles.zip

Hi Laurent -

I'm happy to hear that this fixed the issue. I believe we will add the policy files to the next IVI installer package, though I need to consult with Kirk and others to confirm.

Hi Laurent -

How urgent is it for you to get a new version of the IVI Shared Components installer with this fix in it? Is this something that can wait 3-4 weeks or do you need a fix immediately?

Hi David,

Our new Platform is not fully ready and we can wait 3 or 4 weeks the new release of IVI .

Hi Laurent,

We have a new build of the IVI Shared Components that we are in the process of testing for release. We would like to see if you are interested in verifying it fixes your issue before we make this build publicly available. Your email address is not in your profile, so you would need to contact me directly via email so that we can send you the build privately. We are not able to post the Shared Components to this forum before they are officially available.

You can reach me at kirk@pacificmindworks.com and I can get you the build. Please let me know at your earliest convenience.