NUnitAddIn 0.9.574 + Visual Studio 2003
A few people have had issues running this latest build under Visual Studio 2003. I know it works on some machines (mine for a start!). Peli has Visual Studio 2002, 2003 and C# Express installed and it worked on all of them. Loren has had it working with just Visual Studio 2003 installed. I am now pretty stumped as to why it works on some machines but not others.
If you have installed NUnitAddIn 0.9.574, please comment here and let me know if it worked. Could you let me know that versions of Visual Studio you have installed and what .NET runtime versions. The more reports I have the better!
Gary Feldman said:
Visual Studio knows about it, but when I try to enable it, I get "The System cannot find the file specified" with error # 8007002 (not that that's much help).
If anyone is familiar with fuslogvw or SysInternals Filemon, you know the drill. ;o)
Update: Thank you Gary Feldman and Frank Adler. Using Filemon we can see the last file loaded was 'NUnitAddIn.ManagedAddIn.Connect.DLL' and where Fusion probed for it. Using fuslogvw (the Fusion log viewer) I can see what the problem is.
LOG: Processing DEVPATH.
LOG: Private path hint found in configuration file: PublicAssemblies;PrivateAssemblies.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///C:/Program Files/NUnitAddIn/NUnitAddIn.ManagedAddIn.Connect.dll.
LOG: Assembly download was successful. Attempting setup of file: C:\Program Files\NUnitAddIn\NUnitAddIn.ManagedAddIn.Connect.dll
LOG: Entering run-from-source setup phase.
ERR: Error extracting manifest import from file (hr = 0x80131107).
ERR: Failed to complete setup of assembly (hr = 0x80131107). Probing terminated.
'NUnitAddIn.ManagedAddIn.Connect.dll' is auto generated when the add-in is installed. In this case it is being compiled with .NET 2.0 which isn't compatable with Visual Studio 2003/.NET 1.1. The installer was built with .NET 1.0. If .NET 1.0 is installed this is used and a compatable file is generated. If .NET 1.0 isn't installed then the newest .NET runtime is used (2.0) and an incompatable assembly is generated. For some reason I thought a runtime with the same major version number would be used if available. I wonder if the current behaviour is by design?
I've done a new build with ascending 'supportedRuntime's defined in the installer's .config file. This should have the intended effect (so long you're using a version it knows about!). I say should because Visual Studio 2003 stopped working when I uninstalled Visual C# Express. I'm afraid I haven't been able to test it. =o( Please let me know if it works.