An approach I have not yet seen elsewhere, and executed very elegantly: http://jejacks0n.github.com/mercury/

 

Tags: | Categories:

Windows 8 wouldn't let me activate, and kept giving a warning and error when trying to activate.

I downloaded Windows 8 from my MSDN subscription, so totally legal (I'd assume).

 

This nice little post did the trick for me:

http://social.technet.microsoft.com/Forums/en-US/w8itproinstall/thread/35b0308d-455e-4f80-a135-ae1b0d987792/

Tags: | Categories:

A problem when collaborating on web.config file

The same applies to an app.config file, of course.

When working with web.config file, a problem arises once multiple developers are working on the same application. The config file may contain machine or environment specific settings, which are different between developer machines and target (development/test/staging/production) environments.

Requirements

  • I do not want to think about what to do with my config settings during development, because of process obligations. When I add a setting I add it, and there it ends. Optionally, I also add the setting values for all possible target environments.
  • I do not want to notify other developers that I have added a setting. They need to receive it automatically
  • I do not want to store settings in multiple places (eg. seperate xml's). I want one config file.
  • I do not want to roll my own system, but make use of existing techniques of .NET and Visual Studio as much as possible.
  • Settings in deploys need to be handled without much hassle.

Options

On handling this problem, there are a few options. 

Check-in the file

Check-in the file, overwrite each others settings, and try not to forget to not check in yourself.

Well, this is not really a solution. I've been here, this is exactly the problem that needs to be fixed, this causes lots of friction during development. 

Don't check-in the file

Can't check-in the file? Let's have some self-control and don't check in our config changes. We know how long that's going to last. One moment of carelessness and the system is lost.

Ignore the file

We can tell our source control system to ignore the files. This way we don't have to be disciplined. Everyone can use their own setting values.

This solves the problem of not overriding each others settings, but introduces new problems.

How will other team members receive the setting?

How will you deploy your new settings to the target environments?

You could add an extra "central" configuration file, which can be used for deploys and consulted by other team members. But that causes the settings to be in 2 places which then needs to be maintained again.

The most elegant solution so far

Following is an approach that seems to be fixing all of these problems:

We have one single, checked-in and complete web.config file, developer setting overrides and target environment overrides for deploys. And we are only using built-in techniques.

Developer setting values for appSettings

The appSettings section provides an option to override settings in a separate file. Settings can be added to the central file and overridden in a separate file. Developer specific values can then be added to the separate file.

<appSettings file="web.dev.appsettings.config">

The contents of that file looks like:

<appSettings>
	<!-- PUT YOUR LOCAL DEV CONFIG OVERRIDES HERE -->
</appSettings>

Developer setting values for connectionStrings

The connectionStrings configuration section does not have an attribute like file. However, there exists an attribute for any configuration section element: 

configSource

This attribute does not allow specific settings to be overridden, but does allow putting a whole config section in another file.

You can then use it as follows:

<connectionStrings configSource="web.dev.connectionstring.config" />

And then put the whole section in a separate file.

<connectionStrings>
	<add 
		name="mainconnectionstring" 
		connectionString="..." 
		providerName="System.Data.SqlClient" />
</connectionStrings>

What to check in?

The files can be arranged, so that there are template files for the developer files in a separate (solution) folder.

When a developer starts working on the project, he can copy the files from there into the Web project. The files are known in the project, so they will be indicated as "missing", until you copy-paste or create them.

These template files are checked in, obviously. The local version is not checked in.

These files do cause second versions of config files, which could be seen as friction. But since these files will remain empty, they need no management or maintenance at all.

How are deploys handled?

For deploys, we use Web Deploy and of course, for deploys we make use of the config transforms. The developer specific settings can be removed and the target environment settings can be put in place:

Below is an example of a config transform, which does the necessary actions to create a correct web.config for target environments:

Some words of explanation:

  • RemoveAttributes(file): this transform is used to remove the file attribute from the appSettings section
  • xdt:Transform="Replace" on connectionStrings: this will replace the whole connectionStrings section.

 

<?xml version="1.0"?>

<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">

	<appSettings xdt:Transform="RemoveAttributes(file)">
		
		<!-- put regular transforms here -->
		
	</appSettings>

	<connectionStrings xdt:Transform="Replace">
		<add name="mainconnectionstring" connectionString="..." />
	</connectionStrings>
	
</configuration>

Conclusion

  • This solution nicely extracts all developer setting overrides into other, not checked-in, files. 
  • There is a single, central, config file. 
  • The settings can be read without using any custom code. 
  • Deploys just work by using standard techniques of the framework.
Tags: , , , | Categories:

September 1210

.NET developer tools list

Non-exhaustive list of useful tools:

.NET General

ILSpy (http://wiki.sharpdevelop.net/ILSpy.ashx)

Open source .NET browser and disassembler.

Or: Telerik JustDecompile, or JetBrains DotPeek, all free tools.

 

HTTP and webservices

Fiddler

Obviously

SoapUI (http://www.soapui.org/)

Handy tool for scanning wsdl & sending SOAP requests.

 

.NET Files and filesystem

Working with CSV files: http://filehelpers.sourceforge.net/ 

 

Visual Studio

Slow Cheetah (http://visualstudiogallery.msdn.microsoft.com/69023d00-a4f9-4a34-a6cd-7e854ba318b5)

Free extension, enables config transforms while debugging.

 

SQL

SQL Dumper (http://sqldumper.ruizata.com/)

Free tool. Very useful for dumping SQL data into insert/update scripts.

DB Comparer (http://dbcomparer.com/)

Free tool. Comparing 2 databases. However, it doesn't generate the change scripts to syncronize the databases. OpenDBDiff does.

 

Open DBDiff (http://opendbiff.codeplex.com/)

Free tool. Basically does the same as DB Comparer, but WITH change scripts generation.

 

SQL Delta (http://www.sqldelta.com/)

Commercial tool. Compares database contents, as apposed to schema (like DB Comparer and Open DBDiff do).

 

 UX and design

Indigo (http://www.infragistics.com/products/indigo-studio/)

Fantastic free tool from Infragistix for creating rich prototypes.

 

System

Moo0 System Monitor (http://www.moo0.com/)

Free tool. Monitor what is hogging your system resources.

SlySoft Virtual CloneDrive (http://www.slysoft.com/en/virtual-clonedrive.html)

Free tool. ISO and BIN mounting.

Tags: | Categories:

ASP.NET MVC has a somewhat hidden, but pretty well known setting to build views when building an MVC project.

This setting can be enabled and disabled in the csproj file, by opening it up in a text editor.

The setting is called 

<MvcBuildViews>false</MvcBuildViews>

By enabling the setting (replace false with true, duh :-), aspnet_compiler will be run to compile the views.
Enabling this setting is very useful, because otherwise code errors in the view do not get noticed until runtime, and might not be noticed in time.

However, there's downside: enabling this setting slows down your builds quite a bit.

There's a way to realize fast(er) builds on the developer machines, by letting the view compilation only happen on the CI builds.

 

If your developer builds are built using the Debug configuration, and CI builds happen using the Release configuration, you can change the .csproj file as follows:

<PropertyGroup Condition=" '$(Configuration)' == 'Debug' ">
    <MvcBuildViews>false</MvcBuildViews>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)' == 'Release' ">
    <MvcBuildViews>true</MvcBuildViews>
</PropertyGroup>

Alternatively, you can also, set up a property especially for that, and then make sure msbuild is called with that property set to true.

Eg: 

<PropertyGroup>
    <EnableMvcBuildViews>false</Configuration>
</PropertyGroup>
 <PropertyGroup Condition="'$(EnableMvcBuildViews)' == 'true'">
    <MvcBuildViews>true</MvcBuildViews>
</PropertyGroup>
Tags: , , | Categories:

I used to blog about AutoCAD and .NET over at http://cupocadnet.blogspot.com/ . I'm not really working on that type of projects anymore, and decided to start this blog for more ASP.NET (MVC) and web development stories.

Tags: | Categories: