Measurement Computing   Easy to Use | Easy to Integrate | Easy to Support catalog banner

A Brief discussion on the .NET framework and the managed...

Expand / Collapse

A Brief discussion on the .NET framework and the managed MCCDAQ.DLL

Recently a customer asked,
"I assume that your CD installs the drivers in the mysterious Global Assembly Cache.   I also assume that it's possible to put the relevant DLLs in a local directory with my .NET project and thereby maintain multiple versions. If that is true, exactly WHICH DLLs do I need, and is it just enought to put them in the BIN folder of my project?   I assume that I'll have to also modify my project REFERENCES as well?"

My response:

The part that I’m missing from you is to know how you install your test programs.  If you are creating your own MSI from a .NET deployment project, then this whole matter gets shortened to the statement “just let the GAC (global assembly cache) take care of it.”  In this way, each time you create a deployment .msi, it adds the correct version of the .NET framework required by the MCCDAQ.DLL, then when you run the installer if an entry is not present in the GAC it adds an entry, if the entry is present, then it ups that .DLL’s counter by 1.  The same is true for the .NET framework.


If you are not installing your programs from a .MSI created by a .NET deployment project, well that’s when there’s a whole lot of caveats.  In a nutshell, it falls to you to keep track of which MCCDAQ.DLL was installed and how it gets installed and accessed.  Depending on which version of InstaCal/Universal Library/MCCDAQ CD you used will have a huge bearing on this, as will the .NET framwork version.  We currently offer support for Visual Studio.NET 2005 and up, so the version of the framework that was compatible back then is where we start.  However, depending on what version of the .NET framework you have or had on your system will over ride that if you had a newer version.  So as you can see it can get out of hand pretty fast depending on what version of the MCCDAQ cd, Windows OS, and/or Visual Studio you are using.  Oh and if you are using some other 3rd party device or software, add that into the equation!

I write a lot of demonstration programs here, so I provide source code examples.  I don’t include the MCCDAQ.DLL with my samples.  So when someone downloads the sample program, there is always the chance they will need to update the reference to MCCDAQ.DLL.  I’ve also created DLLs of my own design for graphics, which I purposely don’t strong name nor GAC because that one I DO want to give to customers, but I don’t want the support headaches for this.  However, since it is not GAC’d then it becomes dependent on the link to the folder where I had that file stored (as apposed to installed or GAC’d) which is a different headache.  I create families of samples and I don’t want my DLL to be located in every sample program I send so I put it on the root folder of my samples and reference it from there, but if someone moves it or udpates it, then the reference has to be updated at the very least or removed and re-added worst case.

So in conclusion, it all comes down to how you choose to install your program.  If you create an .MSI, then there is no problem.  If you just create an .EXE or source code to move to a target computer, you will have these kinds of problems.

Rate this Article:

Add Your Comments

For comments email

Article ID: 50325

Last Modified:2/21/2012 8:30:46 AM

Article has been viewed 2,576 times.