EDN Admin
Well-known member
In my company we have a very complex application that involves software written in multiple languages (National Instruments LabVIEW and its multiple libraries, including DAQmx, which in its turn uses who-knows-what), C++ with MFC, plain C with Windows API,
managed C++, C# with .Net 2.0, etc. I keep my PC up to date with all Microsoft Updates and this seems to be causing a lot of trouble because our product is part of an embedded system and is never connected to the Internet, thus, it cannot (and should not need
to) get updates. I am actually now involved in a different project (the successor to this one, which is "only" C# .Net 4 and C++/WinAPI) but I am still called upon to support the legacy edition (the parts that I wrote). The trouble is that if I were to recompile
a component and give it to the engineer who supports the old product, hell often run into problems where the new component will not run on the target system (which we deploy using an automated OPK installation of Windows).
The latest example was a crazy chase of .Net 2.0 updates, just to find that the (main) problem (so far) turned out to be with the VC++ redistributables, but the .Net updates are also causing a lot of grief. Lets start from the top. So, a component is crashing
and he requests that I sent him a debug version. I compile one on my up-to-date PC and it would not run on the new PC - it only shows an error box with the ominous "the application has failed to start because application configuration is incorrect..." message.
So we start trying to figure out what it takes and in the process we go through a hundred security updates and service packs, etc. Not to mention that it is extremely difficult to find through Microsoft what patches are available for a given product. You cant
just have a single patch that supersedes all previous ones (that would be a service pack, which only come once every few years) and you cant even find which is the latest. I wish I could just search for "list of all .Net 2.0 updates since November 2010" or
"latest .Net 2.0 update". I just wish an executable would have the information necessary to know which updates it would need to have in order to run. It used to be very simple in the era of "DLL hell" - if the executable would not run, it would tell you what
DLL is missing (and you could use Dependency walker, or something like that) and all youd need would be to find the proper version. Not to mention, you could have compiled the libraries statically and avoid all that.
But, most importantly, why do those patches have to disable/break the executables? I know that security issues are important, but in all those cases like ours, where the PC is not under any threat, why do we have to deal with that?
Where I am right now in todays saga is I have updated the system sufficiently to have the release versions of the various components work but for some reason the debug versions would not. What is up with that? There is absolutely no information coming up
when I search Microsofts website for updates that apply to debug versions of executables, so I am at a loss. In the olden days, you could check for dependencies and find that you might not have the debug version of the CRT, or something like that, but what
do I do now?
How do you guys deal with this new "update hell" and do you have any recommendations for my case? Thank you in advance.
Kamen
P.S. I should mention that I have run "ngen update", so the .Net 2.0 compilation targets are up to date after all the updates were installed. Im tired of searching for updates, applying everything that comes across my eyes (definitely, everything that shows
as installed on my development PC is on the target, too), and still, although the release version would run fine, the debug version would not.
K.
<
Just jumped from VS 2005 SP1 to VS 2010, native C++ and C#, transitioning from 32-bit Windows XP to 64-bit Windows 7; Mountain time zone.<br/>
View the full article
managed C++, C# with .Net 2.0, etc. I keep my PC up to date with all Microsoft Updates and this seems to be causing a lot of trouble because our product is part of an embedded system and is never connected to the Internet, thus, it cannot (and should not need
to) get updates. I am actually now involved in a different project (the successor to this one, which is "only" C# .Net 4 and C++/WinAPI) but I am still called upon to support the legacy edition (the parts that I wrote). The trouble is that if I were to recompile
a component and give it to the engineer who supports the old product, hell often run into problems where the new component will not run on the target system (which we deploy using an automated OPK installation of Windows).
The latest example was a crazy chase of .Net 2.0 updates, just to find that the (main) problem (so far) turned out to be with the VC++ redistributables, but the .Net updates are also causing a lot of grief. Lets start from the top. So, a component is crashing
and he requests that I sent him a debug version. I compile one on my up-to-date PC and it would not run on the new PC - it only shows an error box with the ominous "the application has failed to start because application configuration is incorrect..." message.
So we start trying to figure out what it takes and in the process we go through a hundred security updates and service packs, etc. Not to mention that it is extremely difficult to find through Microsoft what patches are available for a given product. You cant
just have a single patch that supersedes all previous ones (that would be a service pack, which only come once every few years) and you cant even find which is the latest. I wish I could just search for "list of all .Net 2.0 updates since November 2010" or
"latest .Net 2.0 update". I just wish an executable would have the information necessary to know which updates it would need to have in order to run. It used to be very simple in the era of "DLL hell" - if the executable would not run, it would tell you what
DLL is missing (and you could use Dependency walker, or something like that) and all youd need would be to find the proper version. Not to mention, you could have compiled the libraries statically and avoid all that.
But, most importantly, why do those patches have to disable/break the executables? I know that security issues are important, but in all those cases like ours, where the PC is not under any threat, why do we have to deal with that?
Where I am right now in todays saga is I have updated the system sufficiently to have the release versions of the various components work but for some reason the debug versions would not. What is up with that? There is absolutely no information coming up
when I search Microsofts website for updates that apply to debug versions of executables, so I am at a loss. In the olden days, you could check for dependencies and find that you might not have the debug version of the CRT, or something like that, but what
do I do now?
How do you guys deal with this new "update hell" and do you have any recommendations for my case? Thank you in advance.
Kamen
P.S. I should mention that I have run "ngen update", so the .Net 2.0 compilation targets are up to date after all the updates were installed. Im tired of searching for updates, applying everything that comes across my eyes (definitely, everything that shows
as installed on my development PC is on the target, too), and still, although the release version would run fine, the debug version would not.
K.
<
Just jumped from VS 2005 SP1 to VS 2010, native C++ and C#, transitioning from 32-bit Windows XP to 64-bit Windows 7; Mountain time zone.<br/>
View the full article
