Uniquely named .NET dlls in VS to force validation of sequences by developers

[MatLaroche]

I know this is actually a in VisualStudio and .NET, but I believe the solution could be useful for TestStand developpers that use the .NET adapter.

I'm trying to find a way in Visual Studio (2008) so that when developers build their dll, the name of the dll would be automatically myDLL_3.2.1.0.dll where 3.2.1.0 is its assembly version.

When we release a new dll version, all the test sequences will use the new one since test station are synchronized with latest release. It is impossible for us to revalidate all the test sequences for each products with every release of a dll. It would take weeks every time to get all the setup to test it (hardware especially). So by making sure developers build automatically a unique named dll, I have the guarantee that it will impact only the sequences which they make the change for and WONT impact other sequences using it.

If later a developer wants to use a more recent version of dll, he can easily target the new one and validate that his sequences are still ok.

Is there a way of doing that? I've seen many post-build event examples and ways of editing project file in VS, but nothing close to what I want to do. I want developers to use one common .NET solution, but when they change the assembly revision, the dll built has a unique name (based on revision).

Maybe there's another way of doing that?

Thank you.

[asbo]

This really isn't TestStand-related at all, so you'll probably find much more help on a .NET or Visual Studio forum. However, this post on Slashdot may give you some information.

[MatLaroche]

Yes, I've posted in VS forums of course. 🙂

I was looking for advices or another way of handling this situation. Working in a test environments like many of us do, there must be differents approaches for handling releases of .NET code modules. Since you can only specify the dll name in the step Module tab, updating dlls on our station automatically "update" the sequence with the new code module.

In a company with hundreds of test sequences and products, different developers work on different dlls and sometime share code. If one update a dll and release a new version for its product X, but product Y also use the same dll and both products are tested on the same station, product Y is also impacted. However, the developer supporting product X probably didn't validate his changes with product Y (or simply would like to do it later).

I think our problem is that we use a common directory for DLLs.

We could keep the same name for all (with or without same version) and release them next to the test sequence (or found in search dir related to sequence), it should prevent the problem of impacting other sequences (and allow us to share code) when new ones are released. Of course, it means that the same dll could be on the station in different folders, but having a good search directory logic, it would be ok.

I guess I just needed to explain it to have new ideas. Feel free to add anything if you have a better solution.

[dug9000]

I'd recommend using different subdirectories and specifying your modules relative to the subdirectory as follows:

Module Paths Specified:

3.1.0.0\MyAssembly.dll

3.2.0.0\MyAssembly.dll

By specifying partial relative paths in your step modules like this, you avoid the possibility of accidently loading the wrong one.

Hope this helps,

-Doug

[MatLaroche]

Thank you, this is a good idea also.

For my original question, which was more .Net oriented, I got an answer on the .net forum.

Feel free to tak a look if you're curious about building dll that rename itself automatically with its assembly version.

http://social.msdn.microsoft.com/Forums/en-US/vseditor/thread/fa8b55ef-31fe-4ac5-ac76-741ce8b0c311/