LabVIEW lvproj configuration file .net

[m3rl3n]

I think I have problems defining the specific .NET Assembly to be used.  The problem is our company has a dll that a lot of us use and when the assemblies are in the GAC there may be versions that go past the specific version that I want to use.  Refer to the attached jpg to see what out GAC looks like right now.  Can anyone tell me how to properly set the "old" range in the config file so that everything, even including possible future versions of the dll without affecting the one that I need to connect to?

If version 8.0.13.4714 is not installed, then this config file works fine:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="C:\TestApps\Released\TestSet.RCTS(008)"/>
<dependentAssembly>
<assemblyIdentity name="TestSet.RCTS"
publicKeyToken="cf29a0f483c75c4a"
culture="Neutral" />
<bindingRedirect oldVersion="0.0.0.0-8.0.0.26075" newVersion="8.0.13.2784" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>

BUT if version 8.0.13.4714 is installed...

I've tried this way:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="C:\TestApps\Released\TestSet.RCTS(008)"/>
<dependentAssembly>
<assemblyIdentity name="TestSet.RCTS"
publicKeyToken="cf29a0f483c75c4a"
culture="Neutral" />
<bindingRedirect oldVersion="0.0.0.0-8.0.13.4714" newVersion="8.0.13.2784" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>

and it doesn't seem to help. And I've tried:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="C:\TestApps\Released\TestSet.RCTS(008)"/>
<dependentAssembly>
<assemblyIdentity name="TestSet.RCTS"
publicKeyToken="cf29a0f483c75c4a"
culture="Neutral" />
<bindingRedirect oldVersion="0.0.0.0-8.0.0.26075, 8.0.13.4714" newVersion="8.0.13.2784" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>

More importantly, I'm tired of having to go into this file every time someone makes a change on the development station and adds a new version of the assembly.  To me there should not be a old version to ignore (although I think the binding re-direct is a MS command). I think you should be able to specify the one assembly that you want, and it ignores everything else.

Something like this:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="C:\TestApps\Released\TestSet.RCTS(008)"/>
<dependentAssembly>
<assemblyIdentity name="TestSet.RCTS"
publicKeyToken="cf29a0f483c75c4a"
culture="Neutral" />
<bindingRedirect Version="8.0.13.2784" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>

Any thoughts or hints would be greatly appreciated.

[tyk007]

The best suggestion I can give is to not put the assemblies in the GAC - put them in the same folder or subfolder of the LabVIEW project. This lets you explicitly control which assembly is being used.

I believe that the GAC is one of the last search paths the Fusion follows so if you put the assembly in the same folder as your LabVIEW project then it should pick up on this first despite whatever is in the GAC. You can try this out and then use the menu option in LabVIEW to see the .NET assemblies in memory and it will tell you what path it was loaded from.

[m3rl3n]

Great Idea, unfortunately this would not be feasible. We have multiple test solutions on these test stations, with most of them being written in C#. I'm trying to show that a mixture of LabVIEW and C# is a viable option, but it's not going to work if I can't play nicely with the C# people. And this dll must (for whatever reason) must reside in the GAC.

The dll that we all use is our interface to all of the instruments.  I've proven that I can use this interface as well as the C# guys do, but the one hang up is this version issue.  In my subsequent investigations, I have found that almost to a person, the C# people use the "Specific Version" property set to TRUE when referencing that dll. It seems like I should be able to do the same.

If you reference this article: https://stackoverflow.com/questions/24022134/how-exactly-does-the-specific-version-property-of-an-as...

I'm curious if the xml code under the "When in "Specific Version" checked?" paragraph could be added to the *.lvproj.config?

All that said, I could make a copy of the dll and put it into the project folder, it's just that I was trying not to "bloat" things when I didn't have to.  Different versions (and the same version that I will have in my folders) will still end up going into the GAC though...

Thanks

[tyk007]

The property you are referring to is an MsBuild-specific property related to the Visual Studio project structure when compiling a new assembly. It is only of value during compilation using MsBuild. It has absolutely no bearing on the use of an assembly hosted inside the CLR  - you already have a compiled assembly and now want to specify runtime binding. The best option I am aware of to try and specify this during the binding process with Fusion you already know and yes you would have to update it to specify which version specifically it there are multiple to choose from.

As for the LabVIEW lvproj file - it is also a tool-specific file that contains configuration of a project in a specific format that would make no sense to Visual Studio or MsBuild. Since it is a project file, not an actual running executable (in development that would be LabVIEW.exe) the additional .config won't work since Fusion looks at the executable hosting the CLR - it has no knowledge or understanding of LabVIEW projects, much like LabVIEW has no understanding of Visual Studio Projects and Solutions.

Unless your assembly is really big (we're talking dozens of MBs here) I would suggest that the bloat you describe pales in comparison to any maintenance head-ache you already have. Plus, if you are using source control (which you are of course....) then you only really have a few projects checked out on disk anyway.