.NET Compiler or Setup is Non-Deterministic, Solution?

[Dave L]

This is a strange problem that's plagued me for years using the .NET tools.
The problem is this:

..NET applications installed on a virgin machine (framework installed, but no
..NET tools installed) fail with an expection when the application starts.

The application works in these configurations:

1) Runs in the debugger with Debug or Release builds
2) Release build, installed on a machine with the framework and .NET tools
installed
3) Debug build, installed on a virgin machine (framework installed, but not
the .NET tools)

The application only fails in this configuration:

1) Release build, installed on a virgin machine (framework installed, but
not the .NET tools)

The same project, compiled with the same tools, on the same XP Professional
OS creates non-functional installations on my desktop system, but the laptop
worked fine. A week ago, the laptop started having the same problem of
creating bad installations (again installations worked on everything, except
machines without the .NET tools). Installations are created using the .NET
built-in installer.

After trying everything, the solution to get the PCs to create successful
builds was to change each project Optimize Code setting to False, then build
the project; the installation works in release mode on a virgin machine.
Then go back and change Optimize Code to True; project now works in release
mode on virgin machines. Absolutly no code changes or other project settings
made. The PC now just works and creates successful builds for all machines.
I performed the same proceedure on my laptop and desktop PCs, both now work.
Unable to get a bad build on either machine now.

Is this a known tool bug? If so, how can I prevent this in the future? Same
code and same tool project options produced different results, which bothers
me.

A clue might be that the inner expetion text message was:

"File or assembly name Common, or one of its dependencies, was not found."
Common.dll is my mixed language DLL (managed and unmanaged C++). The file,
and its dependencies, were indeeded in the same directory.

The main exeception was: System.TypeInitializationException. My app has 4
projects: 2 C# DLLs, 1 C++ DLL, 1 C# EXE.

Thanks for any assistance.

 

[John Bailo]

Well -- if 'optimize' means optimize for that CPU -- then, if, say, you
move code developed on a Celeron to an Athlon, maybe there would be
problems.

 

[Dave L]

All test systems running Intel non-Celeron CPUs.

Anyone else have any ideas? I can't find a single bit of info regarding this
problem.

Dave

 

[Dave L]

Further testing reveals the Optimize Code option seems to have no effect.
The solution seems to be this:

1) Open the solution

2) Set the Configuration Manager to "Release"

3) Exit Visual Studio

4) Start Visual Studio and open the solution again

5) Preform the build (solution still has the "Release" setting above)

It seems that if a Debug build is used, then a swith to Release will
sometimes not be successful. Visual Studio needs to startup with the projuct
already set to Release. I think something in the VS compiler still has
leftover dependencies on debug MFC dlls, even though a switched to Release,
a clean solution, and total rebuild is performed.

Any confirmation of this VS bug?

 

[John Bailo]

It seems that if a Debug build is used, then a swith to Release will
sometimes not be successful. Visual Studio needs to startup with the projuct
already set to Release. I think something in the VS compiler still has
leftover dependencies on debug MFC dlls, even though a switched to Release,
a clean solution, and total rebuild is performed.

Could it be that your references, which are attached to the release or
debug build are different.

That is:

..exe Debug build uses

Ref1.dll (Debug)
Ref2.dll (Release)


..exe Release build uses

Ref1.dll (Release)
Ref2.dll (Debug)

 

[Dave L]

Nope. Same references in Debug and Release.

I think the VS build just contains a stale reference to a debug MFC version
DLL even though a complete rebuild is performed. Exiting VS and starting
again, with the Configuration Manager already set to Release seems to fix
it. Least there is a work around, but it was difficult to find.

Dave