Problems with NI deployment after Windows Update

[shansen]

After performing a Windows Update, all of my measurement studio project installers (using VS 2010 setup and deployment project) stopped including the VC++ merge modules.

Long story short, the update upgraded my Microsoft_VC100_CRT_x86.msm and Microsoft_VC100_ATL_x86.msm files, and because the new files had different version numbers the installer couldn't find the dependencies for the NI merge modules.

I fixed this issue by overwriting the new MSM's with the older files.

My question is this: how can I prevent this from happening in the future? Turning off Windows Update isn't an option for me.

It seems to me that the NI libraries shouldn't care about the specific version of the VC100 MSM's. If VC100 gets upgraded, the upgraded version should be listed as a dependency of the NI libraries. Is there any way to make this happen?

-Steven

[Josh_L1]

Hi Shansen,

Thank you for bringing this to our attention. Unfortunately, these look like they are Microsoft merge modules. Please refer to the merge module table for more information. It's listed under Measurement Studios Help, search the key Measurement Studio Merge Module and Deployment File > Measurement Studio .NET Merge Modules.

Manually overwriting the new MSM files is probably your best bet.

Regards,

Josh L.

[shansen]

Josh,

I realize that those are Microsoft merge modules, but I was wondering if there is any way NI can compile their libraries so they don't rely on a specific version. 

At the same time, I realize that Microsoft doesn't always make things easy, and maybe it is completely impossible to make everything version independent.

I think NI has done a great job with Measurement Studio in general, but the fact that I can't just drop DLL's in the right folder and go has been a huge issue for me (in addition to the lack of WPF support). I seem to regularly have trouble deploying MS applications and, although I always get it to work eventually, it seems to take a considerable amount of time.

If the NI Measurement Studio development team could look at simplifying the deployment process for future versions I think many developers would appreciate it.

-Steven 

[Josh_L1 · Accepted solution]

Hi Shansen,

Thank you for the compliment. We try very hard to make the best product possible.

Unfortunately, there is little we can do in this case. Since Measurement Studio runs in the Visual Studio development environment, application distributions are all handled by Visual Studio. I would suggest contacting Microsoft technical support regarding this issue.  

Regards,

Josh L.

[JonathanN]

Hi Steven,

I wanted to throw in my thoughts as to probably what happened. The Measurement Studio merge modules have a dependency on the Visual C++ merge modules. This dependency information is specified in ModuleDependency table. We (NI) have to give a specific signature and version of what we depend upon (e.g., we can't say something like "we depend on this wildcard signature with this wildcard version; this is a restriction at the Windows Installer level). What sometimes happens is this:

1. Microsoft rolls out a update that changes the module signature of the MSMs that we are depending upon (e.g,. this is bad to do since its breaks existing clients like use)
2. When Visual Studio goes to create a setup project, it looks at our MSMs ModuleDependency and it tries to locate those MSMs. The problem is that the updated Microsoft Visual C++ MSMs have a different signature/version and thus Visual Studio can't locate those MSMs. Thus the Visual C++ MSMs don't get included in your setup project.

I understand your concern and we do have an item in our bug database that is tracking this issue. Even though the problem is really at the Microsoft level, we want to do some investigation to see if we can get around this issue.

Hope this clarifies things a little!