I am playing around with R#-plugins these days. I have started off with this nice introduction. Unfortunately it silences about some problems that may occur to you in the beginning.
1) When trying to copy the given source code you’ll mention that all the classes are unknown to Visual Studio, because all a lot of references are missing. So far I have no clue about the R#-class-architecture. So I started .NET Reflector, open ALL the .dlls in the R#/bin-folder into Reflector and use the search to find the .dlls to reference in my project.
2) When you have your first R#-plugin ready you want to test it. To do so you have to copy the dll containing your plugin in the R#-plugin folder. You may want to do this in a post-build event like this:
copy $(TargetPath) "C:\Program Files (x86)\JetBrains\ReSharper\v5.1\Bin\PlugIns\WobTest"
When you build your project with this post-build event it fails. This doesn’t work for two reasons. First: Win 7 denies access to that folder. Second: after another start of Visual Studio R# has loaded the plugin so you can’t copy a newer version over it.
My solution to this is a .cmd that starts Visual Studio without R# (
devenv /safemode). I run this .cmd as administrator.
Now at least I can debug my plugins by starting another instance of Visual Studio (not in safemode!)
This solution is not cool, because developing R#-plugin without using R# in the development-process sucks…. any ideas?
a better solution…
Some minutes after I published this post, Benjamin pointed me to this page. Forget about my lines to 2). You don’t need a silly .cmd run as administrator not a post-build event. All you need to do is to start your debugging Visual Studio the the command line option /ReSharper.Plugin followed by the path to your plugin-dll.
When using the Visual Studio 2010 SDK and creating VSIX packages, you will set for some files the Include in VSIX property within your DslPackage.
I’m not sure what append, maybe it happed on a project I imported from an older Visual Studio version. But for this project the property I needed so much was just missing.
If the same happens to you, you can edit the DslPackage.csproj and add the following line:
It worked on my machine and I got this property back.
What’s the problem?
First of all I have to explain to everybody what I’m talking about:
With Visual Studio 2010 Microsoft introduced a new way to deploy extensions to Visual Studio. Instead of creating a setup.exe that copies files, writes to the registry and calls
devenv.exe with the
/setup option one only needs such a VSIX file that does all that is necessary to install an extension.
When working with the T4 (Template Transformation Toolkit) system one creates tt files with some kind of script that is used to generate source code within a user’s Visual Studio project. The Microsoft DSL Tools do the same: every DSL project contains a number of tt files that will generate all the code. If you take a look at such a file, you will only see two lines:
<#@ Dsl processor="DslDirectiveProcessor" requires="fileName='..\DslDefinition.dsl'" #>
<#@ include file="Dsl\Diagram.tt" #>
The magic happens with the include command. The real template code sits in the included file and not within every single project. When installing the DSL Tools extension to Visual Studio all these include files get installed somewhere where they can be found by the tt engine.
For my own DSL Languages I would like do the same: the user projects should only contain such two line tt files and include the rest of the template from other files.
How to deploy tt template files?
The following steps will show you how to deploy additional files with you DSL extension.
I will start from a newly created Domain-Specific Language Designer project. Such a project contains a
Dsl and a
DslPackage project where the
DslPackage project creates besides of the
DslPackage.dll a vsix file to install the designer onto another machine.
Our goal will be to add some tt files to the vsix and make them includable on the installed machine.
- Add a folder to the
DslPackage project and name it
TextTemplates (or any other name)
- Add the tt files to this folder.
- In the properties windows clear the “Custom Tool” property; otherwise Visual Studio will try to execute these templates within the
- set “Build Action” to “Content”
- set “Include in VSIX” to “True”
- Add a file called
Additional.pkgdef to the
DslPackage project with the following content and
- Edit the
source.extension.tt in the
DslPackage project and add the following line within the
With these changes the tt files from the
TextTemplates folder get packaged into the
vsix file and will be accessible using the
<include> tag on the machine where this extension is installed.