NDO offers a lot of comfort due to it's smooth integration in Visual Studio. But Visual Studio builds are not applicable in projects exceeding a certain size or in projects with a continuous build scenario.
Usually this projects are built with command line build tools like Nmake, Nant, or MSBuild. In command line builds the NDOEnhancer won't be launched automatically by Visual Studio. You have otherwise to make sure, that the NDOEnhancer runs after the compilation.
On the other hand the Visual Studio GUI is used to edit, build, and debug parts of the project. The Enhancer should work in this scenarios too. This article shows, how you can accomplish this task.
Suppose you had a project file tree like that:
Project Base Dir
Bin
Source
Solution1
Project1.1
Project1.2
Solution2
Project2.1
Project2.2
As usually, the .sln files reside in the solution directories, the .csproj and .ndoproj files reside in the project directories. After the compilation all binaries should be found in the Bin directory for better deployment (see also the hints at the end of the article). The directory tree under "Source" can be managed by a source code control system like Subversion (SVN).
You might write a script to build the whole project like that:
@cd Solution1
@devenv Solution1.sln /rebuild %%ConfigurationName
@cd ..\Solution2
@devenv Solution2.sln /rebuild %%ConfigurationName
The projects in the solution contain PostBuild events, which copy the binary files to the bin directory:
@copy $(TargetFileName) ..\..\..\..\..\Bin
At this point a problem arises. If you do that with an assembly project with persistent classes, the binary file will be copied before the enhancer gets launched by Visual Studio. Even worse: The NDO Add-in won't be launched at all in a command line build. You can take the following steps to work around that problem:
- Add a batch file which calls the NDO enhancer. In this example the batch file resides in the Source directory and has the name NDOEnhancer.cmd. The first parameter of the batch will be passed on to the enhancer:
@"c:\Program Files\NDO 2.0 Enterprise Edition\NDOEnhancer.exe %1
With the batch file you keep the location of the NDOEnhancer.exe at one place. You might consider having the NDOEnhancer in a Tools directory in parallel to you project tree, so that your command line might look like that:
@"..\Tools\NDO\NDOEnhancer.exe %1
- In the Build Events tab of your project properties page in VS enter a call to the batch file:
@..\..\..\..\NDOEnhancer.cmd ..\..\YourProjectName.$(ConfigurationName).ndoproj
- Disable the NDO Add-in in the NDO Configuration dialog, because the enhancer gets launched with the call above.
Working with different configurations
Usually, if you enable the NDO add-in in the NDO Configuration dialog, NDO generates a NDO configuration file with the name "YourProjectName.ndoproj". If you switch between the Debug and Build configurations, NDO automatically updates the .ndoproj file, so that the NDOEnhancer can find the right obj/Debug and bin/Debug respective obj/Release and bin/Release directories and the referenced assemblies. If the NDO add-in is disabled, NDO doesn't update the .ndoproj file. So you have to maintain a version of the file for each configuration.
- Open the NDO Configuration dialog, enable the Add-in and choose your settings, just as if you would work with the integrated Enhancer launch. Press OK to save the settings. This will produce the YourProjectName.ndoproj file.
- For each configuration (usually Debug and Release) do the following:
- Choose the configuration in the VS GUI
- Open the NDO Configuration dialog and press "Save As...". Save the file with the name YourProjectName.ConfigurationName.ndoproj. In case of the Debug configuration the file would have the name YourProjectName.Debug.ndoproj.
- After saving the specialized files for each configuration open the NDO Configuration dialog again and disable the NDO Add-in. Press OK.
- Repeat the whole procedure, if your project references change or if you want to change settings like the VerboseMode. Note, that NDO keeps your settings in the .ndoproj files, even if you disable the add-in. Make sure, to enable the NDO add-in before you save a specialized version of the .ndoproj file. Otherwise the enhancer won't be launched.
With this method the builds produced with the VS GUI produce the same output as the builds produced with command line launches of Visual Studio.
Useful Hints
- You should not use Project References in these scenarios. This is not a limitation of NDO, but a useful hint. Reference all assemblies with the "Browse" Tab of the "Add Reference" dialog in Visual Studio. Browse to the Bin directory (that one, which is parallel to your Source directory) and pick up your assembly from there.
- Write your scripts that way that the contents of the Bin directory will be completely deleted at the beginning of each build.
- Also make sure, to delete all bin and object directories in your Source tree. You might use the following .cmd script to do this:
REM cleanup the output directory
@del /Q ..\bin\*.*
REM delete all bin directories in the Source tree
for /F "usebackq delims==" %%i IN (`dir /B /S /AD bin`) DO rmdir /s /q %%i
REM delete all obj directories in the Source tree
for /F "usebackq delims==" %%i IN (`dir /B /S /AD obj`) DO rmdir /s /q %%i
You might have noticed, that the Script, as shown here, should reside in the Source directory.
- Rebuilding the complete project after each SVN Update might avoids much pain, even if it lasts a while.
- You can use the command line build to launch a continuous build triggered by commits of your version control system.