By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,771 Members | 1,685 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,771 IT Pros & Developers. It's quick & easy.

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

P: n/a
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.
Sep 27 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a

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 wrote:
The main exeception was: System.TypeInitializationException. My app has 4
projects: 2 C# DLLs, 1 C++ DLL, 1 C# EXE.

Thanks for any assistance.

Sep 27 '05 #2

P: n/a
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

"John Bailo" <ja*****@texeme.com> wrote in message
news:43**************@texeme.com...

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 wrote:
The main exeception was: System.TypeInitializationException. My app has 4
projects: 2 C# DLLs, 1 C++ DLL, 1 C# EXE.

Thanks for any assistance.


Sep 27 '05 #3

P: n/a
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?
Sep 30 '05 #4

P: n/a
Dave L wrote:
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)

Sep 30 '05 #5

P: n/a
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
Oct 6 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.