Craig Skibo's WebLog

Time to go

CraigSkibo — Tue, 06 Nov 2007 00:37:00 GMT

After 11^1/2 years, I have decided that I need to take a little time away from work and will be leaving Microsoft. So on November 9th I will be walking out those Microsoft doors for the last time.

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

Craig

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

CraigSkibo — Thu, 20 Sep 2007 01:17:00 GMT

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.

Community Content Installer Power Toys - new location

CraigSkibo — Wed, 12 Sep 2007 22:10:00 GMT

Since Got Dot Net was closed down, I have not uploaded the power toys to a new location. I have received a few mail messages asking where they can be found so I thought I would try out the new SkyDrive service, and uploaded it there. You can download from http://cid-262f6eeac88c4916.skydrive.live.com/self.aspx/Public/Content%20Installer%20PowerToys.zip

Visual Studio Shell architecture – Part 1

CraigSkibo — Wed, 06 Jun 2007 22:52:00 GMT

Before getting into how this new Visual Studio Shell Isolated (let’s call it VSSI for short) thing works, I thought I would go into some background of how Visual Studio works, so you can better understand how your program will work.

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

Indroducing Visual Studio Shell

CraigSkibo — Wed, 06 Jun 2007 01:05:00 GMT

I have not been making too many posts here, mostly because I have had my head down working on some new, secret tools for the past few months. Now I can talk about them because today at TechEd we announced what that new tool is, Visual Studio Shell Isolated. That is one of those fancy, descriptive names that Microsoft marketing gives to something that is quite simple, but at the same time powerful. Over the years many people have been creating packages and Add-ins for Visual Studio, but if anybody wanted to use your package, they had to have a copy of Visual Studio (pro or above) installed on their computer or you had to license what we called the PPE (or “Premier Partner Edition” – another beautiful name) and it was not exactly cheap.

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.

Making Add-in development easier

CraigSkibo — Fri, 04 May 2007 00:13:00 GMT

One complaint that we have received about creating Add-ins is about the .addin file. Specifically, why are there two of them? If you move the project file, check into source code control, etc. then the file no longer works or disappears. To make this easier I wrote a small tool found at http://workspaces.gotdotnet.com/VSExtTools under the name .addin Helper. When added as a build rule, it will open the .addin file, modify the path to point to the just built DLL, then save it under the My Documents\Visual Studio 2005\Addins directory.

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.

Hello old, new friend

CraigSkibo — Thu, 15 Mar 2007 20:25:00 GMT

For the past few years, Carlos Quintero has been the MVP working with the automation model. Last night we finally got to meet over dinner for the first time during the Microsoft MVP Summit. I would like to take this time to thank Carlos for all his hard work on the Yahoo! group, the MSDN Forums, his web site which provides many automation resources (http://www.mztools.com), and the other ways he has helped the community over the years. And hopefully there will be many more.

Now taking requests

CraigSkibo — Mon, 26 Feb 2007 23:39:00 GMT

Samples and tools are a big part of the VS SDK, but what we decide are good samples and tools are not always what you need. So here is your chance to let us know what you would like to see. Always feel free to send us mail directly if you do have a suggestion, but here is a forum for you to discuss ideas. I am not talking about something simple like "I need an example of how to get to the X service", but real, substantial samples and tool ideas. I cannot make any promises as to which ones we will do or when they will be available, but we will try our best.

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

Time for a change

CraigSkibo — Sat, 06 Jan 2007 01:57:00 GMT

If you have not noticed I have not posted to this blog in a while. There are many reasons for this, a few of which led me to decide to leave my current position in Visual Studio. For the past year I have not done much with extensibility and instead have spent most of my time working on things that, to me, were not very exciting.

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.

New book now available

CraigSkibo — Mon, 12 Jun 2006 20:14:00 GMT

I know it has been a while, but I just wanted to drop a note that our latest book, Working With Microsoft Visual Studio 2005, is now available in paperback. If you need a copy, you can pick one up from places such as Buy.com, Amazon, etc.

A Man in Enemy Territory

CraigSkibo — Sat, 28 Jan 2006 03:24:00 GMT

The Seattle Seahawks are in the super bowl, I am happy that they are going. But there is one small problem – I am a Pittsburgh Steelers fan. I moved to Seattle almost 10 years ago, and before my move I was born and lived about 60 miles north of Pittsburgh. So while I cheer on the Seahawks any other time of the year, about half way through last week’s Seattle – Carolina game, sides started forming at the friend’s house where a few of us were gathered to watch the game. It was now everyone in this state vs. me. Well, almost everyone, I have noticed a small but growing number of Steelers jerseys in the past week. I have been wearing mine more frequently, which has resulted in finding a few new Pittsburgh-natives that are in the same situation I am in. Oh sure, I get lot of people whispering and talking behind my back. There was one drunk guy when I was out to dinner a few days back that tried to heckle me but didn't do it very well. There was even one little boy that started crying when his mom told him, using her exact words “He wants the Seahawks to lose”, but overall it has not been that bad.

While I will not be back in Pittsburgh for the large festivities when the Steelers win (and they will win), at least I get some of the atmosphere living here in Seattle. Although I must say, football in Pittsburgh is completely different than it is in Seattle. Like I said, I used to live about 60 miles north of Pittsburgh. Even that far away, when I was back home for Christmas, every street corner had a booth setup with somebody selling something with the Steelers logo on it. Everybody that you saw was wearing black and gold. Here, there are some people who are wearing something with the Seahawks on it, but not in the quantity or quality (a t-shirt is not the same as a real, authentic jersey) like they do in Pennsylvania. As I recently read in a news article, Steelers clothing is the Armani and Prada of Pittsburgh. And I saw the effect in December when they were saying the Steelers may not even make the playoffs; I can only imagine what it must be like now.

So nine days from now at the “Big Game” (can you even say that now without getting in trouble?) party I am going to, I will be sitting on one side of a large screen TV. I will be wearing my Bettis jersey, with a Terrible Towel in one hand and some sort of snack food/beverage in the other. And because the party I go to always has the fans of one team on one side of the room and the fans of the other team opposite, looking back at me on the other side of the TV will be many, many angry looking Seahawks fans. But that’s OK, at least I will have one couch to myself.

You can download our book if you are a MSDN subscriber

CraigSkibo — Thu, 26 Jan 2006 22:06:00 GMT

It has been confirmed by a few MSDN subscribers that you can download our book, Working With Microsoft Visual Studio 2005. I have not tried it myself, but it is supposed to be in PDF format. Just click on the Help | Register Product menu item to begin registering, and you should get an email describing how to download it.

Craig

Visual Studio 2005 Automation Samples now available

CraigSkibo — Sat, 07 Jan 2006 02:09:00 GMT

You can now download the automation samples for Visual Studio 2005 at http://msdn.microsoft.com/vstudio/downloads/code/automation/default.aspx. This package includes samples updated to use the new VS 2005 .addin mechanism, new samples for 2005, and many of the old samples were ported to be written in C#, J#, VB, C++/ATL, and C++/CLR.

Because of some problems, the tool GenerateIconData has been moved to the Visual Studio Extensibility tools web site at http://workspaces.gotdotnet.com/vsexttools.

Visual IL source code now available

CraigSkibo — Wed, 07 Dec 2005 23:34:00 GMT

I have upload the source code for the Visual IL language service and project to http://workspaces.gotdotnet.com/visualil. There are a few restrictions that I put on downloading the source code, mostly because I am planning on writing a new book on the sample and I need to be able to ship the sample with the book. But if you notice any issues or wish to contribute, I would be happy to hear from you.

That is a lot easier than I thought

CraigSkibo — Fri, 02 Dec 2005 21:55:00 GMT

For a while now, people have been asking me how to create Satellite DLLs for their Add-ins. My response was always to create your .resx file for each culture, run resgen from a command prompt to create the .resources file, then run al to create the DLL. Finally you need to create directories to contain the Satellite DLLs.

Yesterday the topic of how to create Satellite DLLs for WinForm apps was mentioned, and after finding out a few details and a quick test, there is a much easier way to create Satellite DLLs for an Add-in. First, start the Add-in wizard. Choose all the options you wish, but on the 3rd page, enter @Name as the name of the Add-in and @Description as the description of the Add-in. When you have finished the wizard, right click the project and select Add | New Item, select Resources File, and then enter Resources.culture.resx as the name of your resource file, where culture is the culture name you wish to localize for (for example, en-US for US English). Next, add strings named Name and Description to the resx string editor with any value you wish. When you compile the project, it will automatically create the Satellite DLL, put them in the correct place, and when you run the Add-in and open the Add-in Manager the localized strings should automatically appear.

This exercise also inspired me to create a new sample Add-in to help you create your localized resources. If you select a resx file in the Solution Explorer and select a menu item, a dialog will appear listing all the available cultures. Select a few checkboxes, and the source file will be copied to that new, selected, cultures. You can then open the resource file copy, and localize to the new culture. I should be posting this tool to the automation tools GDN workspace soon.