How to best handle .dll's in source control?

[Daklu]

We have a multi-developer project that currently depends on several DLLs, some of which are kept in windows/system32 and some which are kept in a directory near the code that depends on them. Our developers have the source code tree mapped to different locations on their computer so every time we check out a version another developer has checked in we end up with whole libraries that need to be recompiled and resaved simply because the absolute path changed. As a result, whenever we merge a branch back into the trunk (or forward integrate the trunk into a branch) we have dozens of VIs that have to be manually compared before the merge can be checked in. This overhead is getting cumbersome; it's getting to the point where I will postpone merges simply because I don't want to deal with that.

Is there a good way to handle project DLLs in a source control environment?

[ShaunR]

We have a multi-developer project that currently depends on several DLLs, some of which are kept in windows/system32 and some which are kept in a directory near the code that depends on them. Our developers have the source code tree mapped to different locations on their computer so every time we check out a version another developer has checked in we end up with whole libraries that need to be recompiled and resaved simply because the absolute path changed. As a result, whenever we merge a branch back into the trunk (or forward integrate the trunk into a branch) we have dozens of VIs that have to be manually compared before the merge can be checked in. This overhead is getting cumbersome; it's getting to the point where I will postpone merges simply because I don't want to deal with that.

Is there a good way to handle project DLLs in a source control environment?

We define a relative path inside the vi that calls the dll (using "specify path on diagram"). So it doesn't matter where the dll lives as long as it lives in the same relative position. It means you can move it anywhere and LV won't go searching or re-compiling. The added plus is that (with LV2009 x64) we can also switch DLLs between x32 and x64 depending on which environment it was deveoped/compiled in.

Edited September 2, 2009 by ShaunR

[Daklu]

Good idea! Except it doesn't work in our cases.

I went back and looked a little closer and the libraries in question use .NET Constructor nodes which don't use the path. You have to go through the dialog box to select an object out of those that (I assume) have been registered with windows. The reference to the .NET object is then stored in the class private cluster.

The .NET Refnum control in the class data cluster uses the same dialog box to define the reference type, and I'm guessing this is what is causing the constant resaves. It looks like any VI that uses that reference to call the object's properties or methods triggers the 'vi changed' flag and prompts for a resave because "Name or location of VIs in the file system changed."

Any other ideas?

[ShaunR]

Good idea! Except it doesn't work in our cases.

I went back and looked a little closer and the libraries in question use .NET Constructor nodes which don't use the path. You have to go through the dialog box to select an object out of those that (I assume) have been registered with windows. The reference to the .NET object is then stored in the class private cluster.

The .NET Refnum control in the class data cluster uses the same dialog box to define the reference type, and I'm guessing this is what is causing the constant resaves. It looks like any VI that uses that reference to call the object's properties or methods triggers the 'vi changed' flag and prompts for a resave because "Name or location of VIs in the file system changed."

Any other ideas?

Ahh. I have a rule with our programmers. No .NET and No ActiveX. If a "Texty" wants a feature from one of those technologies, he can get off is arse and write it, and while he's at it, make it really easy for use in LV (i.e no obnoxious referencing). You'd be surprised at how often they come up with a far more elegant solution

Your options are limited. Unfortunately, the modification bitset is read-only-no help there! You could walk the project list using a vi installed in the environment that re-compiles any vi's when a project is loaded,, but I expect your SC would still complain that the file has changed.

The only viable way forward that I can see is to enforce a directory structure so that they can't put the files anywhere and can only check them out to a single "working area" which is the same on all machines. We do this anyway as it means anyone can go to a machines and not spend 10hrs hunting for files.

[Black Pearl]

There is an optin: 'Do not save automatic changes'. That might help.

Felix

[Daklu]

There is an optin: 'Do not save automatic changes'. That might help.

I've tried that. It doesn't help.

[ShaunR]

One thing thats been bugging me all day. You say your having problems with .NET. But .NET assemblies are registered (in much the same way as ActiveX). So in theory, no application (including LV) actually knows where the files are physically located, only if a certain function has been registered. What am I missing here?

[Yair]

What am I missing here?

.NET assemblies can be used in one of two ways:

1. They can be registered in the GAC, in which case you don't need to know exactly where they are, or
2. They can be pointed to directly (by the appDomain, if memory serves, which in LabVIEW I believe is the project). You can do this using the browse button in the dialog.

[ShaunR]

Hmmm. I thought that was only for build.

Does that mean its the project's dependency path thats causing Daklus problems, rather than the vi's?

[Yair]

No, I'm fairly sure the absolute path is kept in the VI. My reference to the project was because I remembered something (probably from Brian Tyler's blog) about the project serving as the appDomain and something else (which may not even be correct, since I'm not a .NET programmer, so it's possible I even made it up) about how the appDomain holds the references to non-GAC assemblies.

That said, I didn't originally read the original question thoroughly, so here are some options:

1. Make sure they're registered in the GAC instead of being all over the place.
2. Use a typedef for the .NET reference (you might wish to do that anyway, since I seem remember problems from LV 7.0 where a DLL was upgraded and the reference broke, but that may have been COM). This probably won't help if I understand the problem correctly.
3. Do a search. I seem to remember someone complaining in the NI forums about LabVIEW asking for similar saves in 8.5 or 8.6.

[Rolf Kalbermatter]

No, I'm fairly sure the absolute path is kept in the VI. My reference to the project was because I remembered something (probably from Brian Tyler's blog) about the project serving as the appDomain and something else (which may not even be correct, since I'm not a .NET programmer, so it's possible I even made it up) about how the appDomain holds the references to non-GAC assemblies.

Just a few remarks here, although I'm not a .Net Guru at all. I'm not sure if app domain is the right word here but LabVIEW indeed registers the project directory for private assemblies. .Net basically only allows two locations for .Net assemblies and that are the GAC and the private assembly directory, which MS might call app domain.

Obviously there is no project directory in a LabVIEW executable and therefore the executable uses the default .Net private assembly directory which is the executable directory itself.

One additional complication is that you can only add strongly named (fully versioned and all) assemblies to the GAC.

Supposedly, all these restrictions are to avoid DLL hell.

The problem here might be really that the .Net reference stores the relative path from the project to the assembly, which would explain the mess you get on different computers causing recompiles all the time.

Rolf Kalbermatter

[Daklu]

Rolf comes closest to what I've been able to discover. This is a .Net limitation, not necessarily a Labview limitation.

Obviously there is no project directory in a LabVIEW executable and therefore the executable uses the default .Net private assembly directory which is the executable directory itself.

This is part of the problem. If the assembly isn't in the GAC, .Net looks in the directory of the executable that is requesting the assembly. In the dev environment that's Labview.exe. I'm not too keen on loading up that directory with assemblies. Looks like the GAC is the only reasonable way to go.

[Rolf Kalbermatter]

This is part of the problem. If the assembly isn't in the GAC, .Net looks in the directory of the executable that is requesting the assembly. In the dev environment that's Labview.exe. I'm not too keen on loading up that directory with assemblies. Looks like the GAC is the only reasonable way to go.

Actually I was thinking the same, but in the case of loading a .Net assembly in the LabVEIW development environment 8.0 or higher, it should in fact use the project directory rather than the LabVIEW executable directory, according to some posts by Brian Tyler, the principal architect of the LabVIEW .Net interface and at that time THE NI .Net specialist, before he went to MS.

But I have to admit I never tested that thoroughly. My only .Net exposure so far was really the development of a binary .Net interface module for LuaVIEW that had mainly to run under LuaVIEW and LabVIEW 7.1.

Rolf Kalbermatter