I have a VSIX package with couple of cu开发者_如何学JAVAstom designers over XML. This package has a flavored project system in which I use some custom build tasks to auto generate code at build time.
First challenge I had to face was with importing .targets files in my project template. I cannot give a fully qualified path to the .targets file in the project template because my package version changes and that makes the vsix installer to drop it inside a version-ed location on the target machine. The way I could solve was to add a user environment variable with package root path and then refer this environment variable in the project template to import .targets file. It works as expected with a caveat.
Now the caveat is how I can create this environment variable during the VSIX deployment process. I tried decorating the package class with a custom attribute derived from RegistrationAttribute
. I overrode the Register method to run Environment.SetEnvironmentVariable()
and it only works when I run the project on my dev box. Apparently, VSIXInstall.exe does not care about running the attribute register during the install.
It will be great if somebody can suggest an approach to solve this issue. I am running out of time and already tried so many things without any success :(
[Including my previous reply to this same question asked over email.]
MSBuild targets/tasks distributed via VSIX are not supported in Visual Studio 2010. The recommendation is for you to use MSI (or similar deployment technology) and drop your targets files to a directory of your choosing under %ProgramFiles%\MSBuild. You can then refer to them in your project templates via $(MSBuildExtensionsPath).
VSIX installation is essentially just an “unzip” of your VSIX. That’s it. There’s no registration or ability to do custom actions whatsoever. As you alluded to, at build time, a tool called CreatePkgDef.exe runs (which is what loads your assembly and calls your RegistrationAttribute) to create the pkgdef file which is included in your VSIX.
I think you’ll need to do one of the following:
- Abandon VSIX and use MSI for deployment (the recommended approach)
- Include the custom targets in the project template. This is bad because now the targets are scattered amongst projects instead of installed to a single location, but it may be an acceptable solution for you.
- Do some initialization (e.g. setting your environment variable) on ‘first launch’ of your package/extension within VS. This of course, means that users will have to know this is a necessary post-installation step.
I realize that none of these solutions is ideal. Please know that better MSBuild support with VSIX is our top requested feature, so we’ve definitely received the feedback.
精彩评论