N
Nick Malik
Instead of posting a problem, I will post a solution to a
problem that I've seen posted many times. One which I
just hit and solved.
I've been using signed assemblies (have to... they are
called by Biztalk over a COM Interop layer). Along the
way, I changed one of the assemblies that my system
depends on, and started getting the following error:
General Information
*********************************************
Additional Info:
ExceptionManager.MachineName: FUDGEFACTOR
ExceptionManager.TimeStamp: 11/26/2003 12:09:42 PM
ExceptionManager.FullName:
Microsoft.ApplicationBlocks.ExceptionManagement,
Version=1.0.1406.18430, Culture=neutral,
PublicKeyToken=98f45edf554ca9ce
ExceptionManager.AppDomainName: DefaultDomain
ExceptionManager.ThreadIdentity:
ExceptionManager.WindowsIdentity: DEV\NICK
1) Exception Information
*********************************************
Exception Type: System.IO.FileLoadException
Message: The located assembly's manifest definition with
name 'MHD.LocalMachine' does not match the assembly
reference.
FileName: MHD.LocalMachine
FusionLog: === Pre-bind state information ===
LOG: DisplayName = MHD.LocalMachine,
Version=1.0.1419.25873, Culture=neutral,
PublicKeyToken=815d65a021f12c25
(Fully-specified)
LOG: Appbase = C:\Program Files\Microsoft BizTalk Server\
LOG: Initial PrivatePath = NULL
Calling assembly : MHD.CISCollector,
Version=1.0.1424.32062, Culture=neutral,
PublicKeyToken=815d65a021f12c25.
===
Using the ILDASM utility, inspecting the Manifest, I was
able to see that my calling assembly: MHD.CISCollector,
was, in fact, asking for an older version of the library
than existed on disk.
I tried dropping the references in Visual Studio and re-
adding them, and recompiling, to no avail.
Apparently, having any application open on the build
machine that USES the older assembly will cause the older
version to be referenced in the new compile. Since I had
NUNIT running, and it had loaded an older version of my
application, the old DLL was still loaded in memory. The
C# compiler picked up the version information from the DLL
in memory, rather than the one on disk, and placed it in
the manifest.
Needless to say, once deployed to another machine, it
failed miserably, since the older version is simply not
available on the test machine. (In fact, I had deleted
the file from my dev machine too, but that didn't take it
out of memory. I had to end the application to have that
effect).
So, for those of you with this problem, who find this
notice (now, or later on Google Groups), I hope this helps.
--- Nick Malik
(e-mail address removed)
problem that I've seen posted many times. One which I
just hit and solved.
I've been using signed assemblies (have to... they are
called by Biztalk over a COM Interop layer). Along the
way, I changed one of the assemblies that my system
depends on, and started getting the following error:
General Information
*********************************************
Additional Info:
ExceptionManager.MachineName: FUDGEFACTOR
ExceptionManager.TimeStamp: 11/26/2003 12:09:42 PM
ExceptionManager.FullName:
Microsoft.ApplicationBlocks.ExceptionManagement,
Version=1.0.1406.18430, Culture=neutral,
PublicKeyToken=98f45edf554ca9ce
ExceptionManager.AppDomainName: DefaultDomain
ExceptionManager.ThreadIdentity:
ExceptionManager.WindowsIdentity: DEV\NICK
1) Exception Information
*********************************************
Exception Type: System.IO.FileLoadException
Message: The located assembly's manifest definition with
name 'MHD.LocalMachine' does not match the assembly
reference.
FileName: MHD.LocalMachine
FusionLog: === Pre-bind state information ===
LOG: DisplayName = MHD.LocalMachine,
Version=1.0.1419.25873, Culture=neutral,
PublicKeyToken=815d65a021f12c25
(Fully-specified)
LOG: Appbase = C:\Program Files\Microsoft BizTalk Server\
LOG: Initial PrivatePath = NULL
Calling assembly : MHD.CISCollector,
Version=1.0.1424.32062, Culture=neutral,
PublicKeyToken=815d65a021f12c25.
===
Using the ILDASM utility, inspecting the Manifest, I was
able to see that my calling assembly: MHD.CISCollector,
was, in fact, asking for an older version of the library
than existed on disk.
I tried dropping the references in Visual Studio and re-
adding them, and recompiling, to no avail.
Apparently, having any application open on the build
machine that USES the older assembly will cause the older
version to be referenced in the new compile. Since I had
NUNIT running, and it had loaded an older version of my
application, the old DLL was still loaded in memory. The
C# compiler picked up the version information from the DLL
in memory, rather than the one on disk, and placed it in
the manifest.
Needless to say, once deployed to another machine, it
failed miserably, since the older version is simply not
available on the test machine. (In fact, I had deleted
the file from my dev machine too, but that didn't take it
out of memory. I had to end the application to have that
effect).
So, for those of you with this problem, who find this
notice (now, or later on Google Groups), I hope this helps.
--- Nick Malik
(e-mail address removed)