I am the only developer working on an ASP.Net MVC project but will share it across multiple computers during development. I'm using VS 2008 and will back up against either Subversion or Git. I'm looking for recommendations on how to configure the project dependencies and web.config files to ease the pain in transitioning between systems.
My web.config file provides the database connection strings that may differ between the systems. What is recommended method to defer this such that it is specific to the dev environment?
My test project is dependent on NUnit, Moq, among other libraries. If the location of these libraries differs across the dev systems does this break the references? If so, how can I mitigate this issue?
My web.config file provides the
database connection strings that may
differ between the systems. What is
recommended method to defer this such
that it is specific to the dev
environment?
For App|Web.config here's what we do:
- Add web.config to svn:ignore
- Copy web.config to web.default.config
- Add web.default.config to svn
- Add the following to your BeforeBuild target
<Target Name="BeforeBuild">
<CallTarget Targets="SetupWebConfig" />
</Target>
<Target Name="SetupWebConfig" Condition="!Exists('Web.config')">
<Copy SourceFiles="Web.default.config" DestinationFiles="Web.config" />
</Target>
FWIW, we also have another target which gets called before SetupWebConfig which deletes web.config if the build server is compiling the project, this allows changes to web.default.config to be included.
You can get fancy and automatically replace content in Web.config using a token inside Web.default.config and some regex. This can also be bundled into the SetupWebConfig target. Let me know if you want to see an example. We do this for setting connection strings and similar stuff on our CI/build servers.
My test project is dependent on NUnit,
Moq, among other libraries. If the
location of these libraries differs
across the dev systems does this break
the references? If so, how can I
mitigate this issue?
My advice would be to include the libraries in your subversion/git repository, place them in a common area, not your project, that way you can reuse them. Reference them using relative svn:externals (remember to set the externals to a specific revision number). This solves your problem plus allows you fine-grained control over what version of each tool you want to use, which is good for testing and maintenance of released products on branches.
For the libraries, i usually make a "Library" project, where all the DLLs are placed, and references are made to those copies.
For the DB strings, make a local system alias on each PC, and place the alias name into the config file instead.
See this for a description of a more or less ubiquitous (for OSS projects at leas) directory structure.
As for connection strings, you can add an entry to your hosts file to map db-server to 127.0.0.1.
I use DropBox to synq across systems. If you just use a SQL Express database during development, you can export later. The connection string would just be pointed to the local system and should work everywhere (as long as you have the same SQL Express version installed). DropBox allows you to use the same solution files and project files, anything you change will be reflected on all systems that have your DropBox installed.
I always maintain a repository just for binary libraries (https://svn.myserver.com/lib) and put all shared binaries there. Then I make use of svn:external to get the correct library from a central storage. However, there are two pitfalls:
This only works when you do not reference the libraries in VS from the GAC but by using the "browse" tab and choose the library from the local directory created by subversion when handling the svn:external property.
On branching you need to "freeze" the svn:externals property by putting a specific revision between the target and the source using the "-r" parameter:
/lib/3rd-party-lib -r4711 https://svn.myserver.com/lib/3rd-party-lib
This way it is possible on every machine to do a check out and just press play to start. Sometimes I even use this to share small tools needed for the build (batch for setting permissions, registring a certificate, etc...)
