1

I'm hoping someone out there can explain this behavior that I'm seeing. There are 3 main parts to my problem:

  1. A Wise setup
  2. A Managed C++ assembly
  3. A C# assembly

The Managed C++ assembly defines an interface, let's call it ISetupHelper. There is a class in the C# assembly that implements this interface (The C# assembly has a reference to the managed C++ assembly). Let's call this class SetupHelper.

Since the Wise setup can't call directory to the C# assembly, we have this managed C++ assembly in between. There is a method that the setup calls to create an interface of a class that implements ISetupHelper. I does this by passing 2 strings to the C++ method, the assembly path (to the C# assembly) and the type name.

The C++ method looks like this:

Assembly^ assembly = Assembly::LoadFrom(assemblyName);
Object^ provider = assembly->CreateInstance(typeName);
WiseServices::SetupHelper = safe_cast<ISetupHelper^>(provider);

This has worked very well for us for a number of years. Now we are trying to add support for Windows Server 2012/R2. These versions of Windows come with 4.5 and 4.5.1 installed respectively.

Here is where the odd problem happens. If the setup is run from a path with a long name it does not work if you run it from the short version of the path. When I say it doesn't work, I mean the cast fails. For example:

  • Running from this directory works: c:\reallylongname
  • This does not work: c:\really~1

I turned on the Fusion logger, and when the cast fails it tries to load the C++ assembly again:

  • LOG: IJW explicit bind. File path:C:\reallylongname\ManagedCPP.dll.
  • LOG: IJW assembly bind returned a different path: C:\REALLY~1\ManagedCPP.dll. Use the file provided.

If you do this exact same thing on a Windows Server 2008 R2 machine with only .NET 4.0 installed, running from the short path works just fine (the cast is successful).

It seems as if something in the CLR has changed in the way it loads assemblies and in particular when loading an assembly with the same name as one that has already been loaded.

Bryan
  • 2,710
  • 3
  • 25
  • 40
  • This is really obscure. I'd assume it has more to do with the operating system. It is getting pretty common to turn short name mapping off. And that this runs as a setup program probably isn't a minor detail, Windows has pretty heavy appcompat to keep ancient installers still working. A call to Microsoft Support is probably your best bet. – Hans Passant Feb 09 '14 at 02:16
  • I don't think it is OS related. I did not mention this, but we tried this on a Server 2008 R2 machine with .NET 4.5 installed and it behaved the same way as the Server 2012 machine. So, it certainly seems to be related to .NET 4.5. – Bryan Feb 09 '14 at 18:53
  • I am from Microsoft .NET team, would like to understand this better. Could you send standalone code that reproduces the issue to netfx45compat at Microsoft dot com? Regards – Varun Feb 10 '14 at 22:31

0 Answers0