Visual Studio Extensibility Forum FAQ Lite

  • Article

What? No email link to talk to the Doctor directly. Yes that is true the email link has been removed from the blog. Dr. Ex and his assistants recommend use of Visual Studio Extensibility Forum instead. Your questions get exposed to a broader audience beyond just the doctor’s staff. Accept our apologies for any inconvenience caused.

With that said the doctor and his team skimmed through recent forum posts and created the first Forum FAQ list. This list tries to address some generic questions that a lot of people have asked about on the forums.

How do I use Visual Studio 2005 SDK on Windows Vista?

Visual Studio 2005 SDK and some of the components it installs assume you can run with admin privileges. In fact, to build a sample or a wizard generated VS Package require the ability to write to restricted sections of the registry and need to run elevated. However you can install the SDK and run samples even with UAC turned on. The doctor suggests that you always run Visual Studio elevated when creating VS Packages. One of my assistants Allen Denver has blogged about this in detail. Feel free to visit Allen’s blog for details.

What is ProjectAggregator2 and why do I care about it?

ProjectAggregator2 is a redistributable component that ships with the Visual Studio 2005 SDK. This component is needed to work around the following issues when developing a custom project type based on the Managed Package Framework (MPF). The component solves two problems for MPF based project classes.

· COM Interop’s VARIANT marshaling behavior. For example Visual Studio implementation expects VT_PTR type for certain properties returned by the project’s IVsHierarchy::GetProperty implementation. The COM Interop marshaler always generated VT_INT instead. Deriving from this wrapper would ensure the right variant type to be returned.

· Visual Studio’s project aggregation implementation. In classic COM aggregation the “outer” object creates the aggregated “inner” object. This “inner” object requires a reference to “outer’s” IUnknown so it can delegate calls to it. The “outer” object is created before the “inner”. In Visual Studio the creation of aggregated projects are controlled by the SVsCreateAggregateProject service. This service recursively creates a chain of aggregated objects. For example when creating a ProjectSubType (sample in VS SDK) project which aggregates the C# project system the “inner” (a C# project) object is created first and followed by the “outer” project (a ProjectSubType sample project). This service then sets the C# project as the inner project for the ProjectSubType project. However since ProjectSubType is implemented in managed code its IUnknown implementation cannot be customized. As a result proper delegation of calls does not happen. By deriving the MPF project type from CProjectAggregator2 class this problem can be avoided.

What’s up with this Package Load Failure Error?

Dr. is pretty sure you have been bitten by this error one time or the other in your life developing packages for Visual Studio or just working with Visual Studio, unless you have been living a life of a hermit. Put in simple words, the package load failure indicates that Visual Studio had problem loading some functionality that a user explicitly or implicitly requested. The typical reasons for package failing to load in Visual Studio are as follows.

  • PLK Validation Failure- Developer could have inadvertently changed either of the following: Package GUID, Company Name, Product Name, Product Version, and Min Edition in the package registration. These values should not be changed after a PLK has been associated with a package. Any changes necessitate a new PLK.
  •  Dependency Issues – Package could have been deployed in a way that either the dependencies are either missing on the machine or they are not in location that Visual Studio can load it from. A user can use ILDASM or Depends.exe or dumpbin.exe to isolate such issues.
  • Exception Thrown – At the time package is loaded by Visual Studio it calls IVsPackage::SetSite method. If the method throws an exception for some reason then the package load fails. The best way to isolate the issue is to debug and step through the code.
  • Improper registration – Typically when you use the /assembly switch. Verify that package is signed appropriately and that registration has the right public key in it.

 

For more information on debugging this failure please refer to earlier post on Debugging Package Load Failures.

I hope you found the information above useful. For your convenience I will also post this on the Visual Studio Extensibility Forum as a pinned post so you can refer to it for there as well. Stay tuned for further updates.

 

Thanks

Dr. eX