Partager via

Why C# and VB are not supported for VS Shell Isolated stubs

  • Article

I have been asked a few times why, when you run our wizard, we generate C++ code and not C# or VB. Some have even tried creating a C# or VB stub exe only to find errors when their program is run. Why does this happen?

A file that is put into the GAC when you install the VS Shell Isolated components is Microsoft.AppEnv.CustomLoader.dll. When a transition is made from your exe to appenvstub.dll a few things happen to get the VS Shell running; one of the first is loading and then modifying how the CLR will find and load components. When you run Visual Studio all the files are within a self contained directory, usually \Program Files\Microsoft Visual Studio 9\Common7\IDE or a sub directory. But when you run your program it can be installed anywhere, and most likely will not be in the same directory as devenv.exe. Because your code and our code will not be in the same place, packages and support code that we install will not be found, and not everything will work as expected.

To fix this, we created a custom loader. The .NET framework has the ability to modify how AppDomains are configured when created, and one of these configuration points is to allow a callback when an assembly cannot be found. The custom loader hooks this call back and, when an assembly cannot be found, calls our loader to help locate the assembly. The problem with this is that you need to set this callback before the AppDomain is created, and the properties of the AppDomain cannot be modified after creation. Since a majority of the Visual Studio .NET Framework code runs in the default AppDomain, you need to hook this callback before the default AppDomain has been created.

If you were to create a stub exe using C# or VB, just running your exe causes the default AppDomain to be created. Since there can be only one copy of the .NET Framework loaded into a single process and because the default AppDomain has been created (and cannot be destroyed), our custom loader will never have the chance to load. So while you could try to write a stub in C# or VB, you would find that shortly after running parts of your Shell would start to fail and not work properly because we could not find all the assemblies that we need to run.

Comments

  • Anonymous
    September 20, 2007
    I do have a different view on the C++ vs. C# vs. VB code for the stub... Do you really expect people to modify the generated stub code at all? (no matter if it's C++, C# or VB code). What about proving a configurable stub in .exe form and just use that? thanks, -VGA.

  • Anonymous
    September 20, 2007
    No, there is no real need for a special Exe that you compile other than:

  1. The name that is passed when calling Setup/Start/Remove. That name needs to be unique to your application and not conflict with another app. So if we had a seperate way of defining that app name, such as looking for an .ini file containing the app name and named the same as the exe but with an ini extension, then that would work fine.
  2. The resource information embedded within the exe. You should be putting your organization name inside the exe in the file version resources. If a user were to view the file version information, having Microsoft in there would be misleading, and a generic name would not point the user to the author. Those are the only two items I can think of at this time.
  • Anonymous
    December 16, 2011
    Is it ok to create have the stub in default appdomain and create a new appdomain to load the rest of whatever appenvstub does ? I agree that having the stub as managed is not going to serve any big purpose, but just curious to know about it :)