You can read more about this on my personal web site at CraigSkibo.com.

Craig

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.

When you click on the icon in the start menu to start Visual Studio, you run a program called devenv.exe. Devenv is a short version of development environment or developer environment depending who you talk to. This exe (we call it the stub) will then load a DLL named msenv.dll – and that is where the majority of the work is done. When you launch any other copy of Microsoft development tools, such as the Express editions, the exe name may change, but the same steps are performed. Some customizations are performed by the stub, for example, the splash screen is displayed by the stub (some users of msenv.dll do not display a splash, such as the Macros IDE used by VS) while other customizations, such as the name to show in the title bar, are passed between the stub and msenv.dll. These values are passed through by an exported function in msenv.dll and this function is responsible for creating the main window, starting the message pump for the window, and doing all the work that is common among all callers of msenv.dll.

When you install the next version of the VS SDK, a new Starter Kit and a couple DLLs will be installed onto your computer. The starter kit will create three projects for you, one project will create an exe which will be compiled into a program that loads and runs your customized version of VSSI. One project contains the “command used” data (we will discuss this in a future post), and a package that you can put code that is specific to your VSSI instance and not intended to in in, for example, Visual Studio. When you run the exe project it will look for a DLL named appenvstub.dll - AppEnv was the internal name before we spent a lot of time thinking up the name Visual Studio Shell Isolated, and the name of this DLL will probably change before we ship it. When appenvstub.dll is found it is loaded, then the exe will call one of three methods, Start, Setup, or Remove to either (shockingly) start the application running, setup registry data, or remove registry data. You will pass the command line switches and the name of your application to one of these three methods. Appenvstub.dll will then perform all the work that a program such as devenv.exe or csexpress.exe currently does, which is package up all the data necessary to send over to msenv.dll, display the splash screen, and then start things running. Packaging up this data and running is not easy to do, so Appenvstub.dll acts as a translator between your exe and msenv.dll by bringing in data stored in the registry. This data from the registry is found by the name passed to the functions exported by appenvstub.dll.

Just a few of the posts that I will be making in the future include (more will be added to this list over time):
• The code generated by the template
• How we create the registry (or how you install without installing)
• Customizing your application
• Command used files
• Converting existing packages for VSSI
• Installing Visual Studio Shell Integrated and Isolated
• Choosing the right install model

What I have been working on is allowing you to, by building a small exe program and editing an even smaller text file that looks like a .reg file, create your own application which consumes the Visual Studio shell. Your program is branded with your company name and logos in any way that you wish, the only place that any Microsoft logo appears is on the splash screen where on the bottom right we put the text “Powered By Visual Studio”. And best of all – it is free!!! You can also distribute the PPE version of Visual Studio Shell, for free!!!

Over the next few posts I will be making a series of postings about how to get started, the tools available, how to distribute your applications, architecture, which version is best for you, etc.

To use the file, save it into your install directory (C:\Program Files\Microsoft Visual Studio 8\Common7\IDE) then add this as your build rule for C# or J#:

"$(DevEnvDir)AddinHelper.exe" "-XmlFile:$(ProjectDir)$(ProjectName).AddIn" "-Assembly:$(TargetDir)$(TargetFileName)" -q

 For VB, you will need to modify the project file. Find the <PostBuildEvent></PostBuildEvent> tag, and change it to:

<PostBuildEvent>"$(DevEnvDir)AddinHelper.exe" "-XmlFile:$(ProjectDir)$(ProjectName).AddIn" "-Assembly:$(TargetDir)$(TargetFileName)" -q</PostBuildEvent>

For C++/CLR projects, use this command line (be sure to set it for both Debug and Release configurations):

"$(VSInstallDir)Common7\IDE\AddinHelper.exe" "-XmlFile:$(ProjectDir)$(ProjectName).AddIn" "-Assembly:$(TargetDir)$(TargetFileName)" -q

Now, as long as all users of your project has the AddinHelper.exe tool in the correct location, the .addin file will be updated with the correct path to the .dll.

Edit: To cut down on blog spam I had comments turned off. I reenabled comments.

So where am I going next? Not too far - just down the hallway. Starting January 15th, I will be working on the Visual Studio SDK team where I will be spending a lot of time working on the MSDN forums, writing blog posts (so you should see more from me here in the future), writing samples, cool tools, etc.