So this is the obvious next best step: a Visual Studio Add-In for DOTNETPP to integrate it (somewhat) with VS. The biggest problem it would fix is ‘the catch’ mentioned in earlier posts regarding open source files that have macros.
The Add-In VSDotNetPP can be downloaded here. The download includes the latest version of DOTNETPP (Version 0.1.10.0).
Do note that this Add-In was built with Visual Studio 2010 for Visual Studio 2010. I do not believe it will work with an older version. The Setup created isn’t the greatest, it’s as basic as installing the files to a directory, and is uninstall-able. I’ll try to create a more comprehensive setup package later, but for now, there are some manual steps.
Registering the add-in
The default install directory is: “C:\Program Files\DOTNETPP\.NET Preprocessor Visual Studio Add-In”. You need to run the batch file Deploy-AddIn.bat to register the add-in with VS. This batch file copies the add-in file VSDotNetPP-Deploy.AddIn to the directory "%HOMEPATH%\Documents\Visual Studio 2010\Addins" which is one of the paths that VS2010 searches for add-ins. As I am using Windows 7, I am not sure if this path is valid for Windows Vista or XP.
You can find the paths that VS2010 searches for add-ins in your options settings by going to Tools->Options->Environment->Add-in/Macros Security. You may place the add-in file in any of those directories. This is the information from MSDN.
After registering the add-in, start VS2010, and you should see a new item in the ‘Tools’ menu called ‘.NET Preprocessor’.
To remove the add-in from VS, just remove the add-in file from the path you put it in and restart VS.
How the Add-In works
The add-in basically does what was suggested in previous posts: it closes the relevant open source files prior to running DOTNETPP… And, it opens them back after the build completes! So with this, you will not be bugged with the dialog asking if you want to reload the file as it has been modified outside the editor and fail the build. With this, you can choose to retain the macros in your source with much less inconvenience. However, I’d still not recommend that. I know it’s an inconvenience, but I don’t know how to set the view of the open file back to where it was before it was closed yet. When I figure it out, I will add that feature.
The add-in will call DOTNETPP for pre-build and post-build, so you will no longer have to add the calls yourself into the pre-build and post-build events in your project settings.
Settings Dialog
There is a settings dialog when you click on the ‘.NET Preprocessor’ menu item in the ‘Tools’ menu. This is basically for editing the DOTNETPP config file. Enter the full path of the config file into the settings dialog, and it will load all the settings. If the config file path is invalid, or it is blank, then DOTNETPP will not run during the build. This is how you can ‘turn it off’.
The rest of the settings have already been explained in the previous post about it.
Some Notes
OK, writing the add-in was really tricky. It was not straight forward at all, and I think I caught most of the ‘catches’, and I’ve been using it, and it works fine for the most part. However, if it is not behaving right, like changed settings don’t seem to be taking effect, I can only suggesting restarting Visual Studio. I know, it’s dumb, but that’s what I did and it was fine. However, in the latest testing, this problem hasn’t turned up, so it’s possible I fixed it. As I said, building add-ins for VS is not straight forward eventhough it looks like it is.
Before I forget, the add-in creates an XML file called VSDotNetPP.xml in your solution path. It is used to keep track of the DOTNETPP config file path.
Send me email at tim@bugslayersrus.com to comment, report bugs, or chat. Or, you could leave a comment here. Thanks.
Posts
No comments:
Post a Comment