My main method exits with a TypeLoadException

The program worked fine until I did this:

1. Added a new class under an existing file and an existing namespace.
2. Added settings to that project the new class belongs to.
3. Build the solution.
4. Build the setup project.
5. Installed the new version on a machine.

When I start the new version on the machine, then I get:

Unhandled Exception: System.TypeLoadException: Could not load type 'SI.AS.CommonLogic.Utils.ErrorLog' from assembly 'SI.AS.CommonLogic.ErrorUtils, Versions=1.0.0.0, Culture=neutral, PublicKeyToken=925c8734ae397609'. at RSMonitor.RSMonitorMain.Main(String[] args)

ErrorUtils is the new class I have added. There was a file with a static class in it. I added another static class under it and added settings to the project. It runs smoothly on my developer machine in debug mode. But I can't install and run it on another machine. The program can call the other static class from the same file. What am I missing here?

** update **

I tried to install it for a 2nd time and checked the DLL. The timestamp matched the latest compiled version and now it works. I have no idea why it didn't work last time, because it is the same package I installed again. But if I get same开发者_运维技巧 error, then I'll try out your suggestions.

Your program looks like it is having trouble locating another assembly, probably called SI.AS.CommonLogic.ErrorUtils.dll. Either that, or it can only find the wrong version of this assembly.

Is this an assembly that is part of your solution?

If so, is it in the "bin" directory on the machines that it is failing to run on (in other words, is this assembly being deployed correctly with your app)?

If not, is this a part of a seperately installed component or application that is installed on your machine but not on the others (ie is this an external dependency that is missing on the other machines)?

One thing that may help here, is to use the Assembly Binding Log Viewer on both the miachine this does work on, and the machine it doesn't to see where it gets loaded from in the working case, and where it is trying to load it from in the failing case.

Note you may need to make a registry change to get this to log all assembly bin info:

Set the HKLM\Software\Microsoft\Fusion\ForceLog registry value to 1 (the value is a DWORD).

It sounds like your DLLs aren't being deployed/overwritten correctly. Try copying your CommonLogic DLL from your development machine to the installation directory and see if it can load it then - and then figure out why!

The other assembly wasn't updated correctly, it is still the old version. Try replacing the assembly by hand with the current version and check if the problem persists; it should go away though.

It sounds like an old version of your assembly is being loaded from somewhere.

A few things to check:

Firstly, have you incorrectly set up a reference to an assembly instead of a project? This can result in subtle, order-dependent build problems. Ensure that the reference type is "project", not "assembly".

Secondly, is the culprit assembly in the GAC on the developer machine? Even if the assembly is a dependency of your build, if it's in the GAC, it may not be copied to your output directory. This problem manifests itself in a very pernicious fashion -- everything looks fine on the developer machine (as it has the assembly in the GAC) despite the build output being wrong, and the customer machine will blow up because the assembly is neither in the GAC nor the install directory. I can't remember if this only applies to assembly references or whether project references will pick it up, too. It's easy to test if it's a problem, though -- just do a clean build, then build your project and examine the assemblies copied to the output directory. They should all be there. If your culprit .dll is missing then you know it's a problem.

I worked at a company that (briefly) built installers for internal releases without using proper assembly versioning, resulting in absolutely terrible problems of this ilk (developer machines would be riddled with assemblies in the GAC).

Check the GAC on both the developer and customer machines. Also try what Josh suggested: Copy the culprit DLL from the developer machine to the customer machine's install directory to see if that fixes it, then work from there.