I have an edit view where a product can be modified. In that view i have an action link to a copy action method to which the id of the current product is passed.

public ActionResult Copy(Guid id)
{
var original = this.Repository.GetById(id);
var viewModel = this.GetNewViewModel();
if (original != null)
{
this.InvalidateCache();
viewModel = this.Mapper.Map(original);
}

viewModel.Id = Guid.NewGuid();
return this.View("Index", this.GetMasterDetailViewModel(viewModel));
}

I got some headache because I was using Html.EditorFor(m => m.Id) on the view, which in the case of a Guid creates a hidden field using the Html.Hidden(HtmlHelper, String, Object).

In the copy action I fetch the existing entity and map it to a new viewmodel(I don’t create an entity in the datastore yet so that the user can cancel the copy process). Then the same view that is used to display an existing product is used to display the copy of the product.

So basically I have two times the same viewmodel(except the id) passed to the same view and then posted back to the same URL. Here comes the problem with Html.EditorFor(m => m.Id).
For some reason in the second postback, the value of the Guid is taken from the model state, aka what you get is a cached value.
For my case this means that after the copy action is called I get the exact same HTML as if I wanted to display the original product. And then obviously if the user edits something and hits the save butten, the original is modified and not the copy.

A workaround for this is to write your own markup like this:

<input id="Selected_Id" type="hidden" value="<%=Model.Selected.Id%>" name="Selected.Id" />

Like this the value is taken from the passed viewmodel, not from the model state and everything works fine.

This behaviour is by design and I think there must be a good reason for it(but I actually don’t speak enough ASP.NET MVC to truly understand why..). For further information here’s a discussion on Stack Overflow about the issue:

http://stackoverflow.com/questions/594600/possible-bug-in-asp-net-mvc-with-form-values-being-replaced

I noticed it in the team explorer, one file kept having the checked-out icon, so I ran the following command in cmd:

tf.exe status $(ProjectDir) /user:* /recursive
Result:
ProductRepository.cs  edit   NT AUTHORITYNETWORK SERVICE C:\...ProductRepository.cs

Aha! To fix this I checked the build log for the workspace name and then tried to used tf.exe again to undo this checkout with no luck:

tf undo /workspace:"TFSURL_1_1;NT AUTHORITY\NETWORK SERVICE"
/server:http://tfsurl:8080 C:\...ProductRepository.cs

But this didn’t worked :(  tf undo didn’t found any checked out files.

Finally I could solve the problem with this hint from Robert Horvick on Twitter:

bubbafat@synclop If you haven’t got a Network Service build checkout solution yet - one way would be deleting the workspace. #tfs

So what I did was this:

tf workspace /delete /server:http://tfsurl:8080 "TFSURL_1_1;NT AUTHORITY\NETWORK SERVICE"

And everything worked fine again.

The problem was that i didn’t RTFM: http://download.microsoft.com/download/7/A/0/7A023209-096F-4F7D-B2BC-831ECC68FF5B/VS2010Beta1Readme.htm

1.3.4 Initial Configuration of Team Foundation Server Should be Run From MSI Program or by Command Line
Initial Team Foundation Server configuration fails on Windows SharePoint configuration if you access the Team Foundation Configuration Tool by clicking the link in the Team Foundation Administration Console instead of by launching Team Foundation Configuration Tool at the end of the installation phase.

To resolve this issue:

If you want to setup Windows SharePoint Server during Team Foundation Server configuration, you must launch the Team Foundation Server Configuration Tool by using one of the two following methods:

· Launch the Team Foundation Configuration Tool by selecting the check box at the end of the Team Foundation Server installation

· If you exited Team Foundation Server MSI program (setup.exe) without launching Team Foundation Configuration Tool, do not start the Administration Console from the Start menu item shortcut. Instead use following command line:

%programfiles%Microsoft team foundation server 10.0toolstfsmgmt.exe configure

After Team Foundation Server has installed and configured Windows SharePoint, you can configure Team Foundation Server by using the Start menu to launch Team Foundation Server Administration Console.

Apparently I closed the configuration wizard after it fired up by the installer and restarted it over the TFS admin console.
After deleting all DB’s and reinstalling, it worked for me. Perhaps even rerunning the configuration wizard would have solved the problem.

CC.NET offers lot’s of things and is very extendable, for instance we wrote a custom labeller to tag our continuous builds. One thing that was always pointed to by co-workers, is the fact, that everything is configured over XML files and for some people this was a mental barrier. The last CC.NET version was 1.3 which was released in June 07, since then there was no new release, imho this looked a bit like CC.NET stands on the holding track somehow.

As we migrated our Subversion repository to another server, we looked left and right for other CI solutions and then stumbled very soon upon TeamCity. TeamCity is a build management and continuous integration solution from JetBrains, supporting both Java and .NET developement teams. The professional edition is free up to 20 build projects, which is quite a bunch and probably enough for much small companies. And it’s completely configurable over a webinterface

Our setup in CC.NET was the following: Per product we had one NAnt script and 2 CC.net projects. One of the CC.NET projects was used for continuous builds and was triggered with each commit to the SVN repository. The other project was triggered nightly and additionaly to the CI project all the AssemblyInfo.cs files in the project were updated with the current version number by the NAnt script, which resulted in dll’s being versioned. So these nightly builds we’re ready to be released as unstable versions to beta testing customers.

The versioning of the assemblies was quite dodgy in CC.NET and required some hacks. We used a similar approach for versioning as described in this post on bloggingabout.net. Stamping the files was actually not a problem, this can easily be done with a c# script task and some regexes within the NAnt file.

The more difficult point was, how do we get the version. We wanted a version number of the following format, major.minor.build.revision. The major and minor number were defined manually in the NAnt script.

Now for the buildnumber, we had a SVN repository containing a xml file with the purpose of containing always the next buildnumber to be used. In the NAnt script we defined a target called “extractbuildnumber” which made a svn checkout of that file into a temporary folder, xmlpeeked the buildnumber into an NAnt property, incremented the buildnumber by one and commited the XML file with the new buildnumber back to the repo.

To get the revision number we called svn log with the –xml parameter from our build script and xmlpeeked the revision number into a property.

This whole procedure got significant easier with TeamCity. For each build configuration in TeamCity you can define the build number format. Within this string you can reference the current build number(assigned by TeamCity itself) with {0} and the current revision number(read from SVN or whatever VCS you use by TeamCity) with {build.vcs.number.1}.

When running this build configuration, this string is evaluated and passed to the NAnt script (to Ant as well for sure) as a property named build.number. The whole process of extracting build and rev number like before with CC.NET gets obsolete with TeamCity. Another advantage of the configurable build number format is the labelling of the builds in TC. What had to be done in CC.NET with implementing ILabeller, can be done in one textbox in the webinterface using properties in TC.

Ah, one more thing to say! TeamCity has integrated diff. What we’ve done before with websvn and linking to it from CC.NET is all there in TeamCity.

All in all the migration was done within half a day and although we could do everything we wanted already with CC.NET, with TeamCity it’s just more fun

In his sample, clicking on the MultiScaleImage zooms in by a certain amount and shift-clicking zooms out. I modified the MouseLeftButtonUp handler so that instead of zooming, the point where the click occured is moved to the center.

A sample which uses Scott’s implementation(and can be adapted to center instead of zooming) is found in the Expression Blend Team Blog.

Heres the XAML:

<UserControl x:Class="MoveClickPositionToCenter.Page" xmlns="http://schemas.microsoft.com/client/2007" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<Grid x:Name="LayoutRoot" Background="Black">
<Grid HorizontalAlignment="Stretch" Margin="0,0,0,50" VerticalAlignment="Stretch" x:Name="GridMain">
<MultiScaleImage Source="voodude/items.bin" x:Name="msi"/>
</Grid>
</Grid>
</UserControl>

And here the handler code:

public partial class Page : UserControl
{
public Page()
{
InitializeComponent();

this.MouseLeftButtonUp += delegate(object sender, MouseButtonEventArgs e)
{
Point newOrigin = new Point();

//width and height of the actual viewport
double viewportWidth = msi.ViewportWidth;
double viewportHeight = msi.ViewportWidth * msi.ActualHeight / msi.ActualWidth;

//the current origin
double currX = -msi.ViewportOrigin.X;
double currY = -msi.ViewportOrigin.Y;

//click position relative to the viewport
double clickX = viewportWidth * e.GetPosition(msi).X / msi.ActualWidth;
double clickY = viewportHeight * e.GetPosition(msi).Y / msi.ActualHeight;

//the center of the viewport
double centerX = viewportWidth / 2;
double centerY = viewportHeight / 2;

//calculate new origin
double newX = currX + centerX - clickX;
double newY = currY + centerY - clickY;

newOrigin.X = -newX;
newOrigin.Y = -newY;

msi.ViewportOrigin = newOrigin;
};
}
}

Fiddler is also able to decrypt SSL traffic. I used it recently to capture traffic over SSL sent by my browser and wanted then to use it again to check if my programmatic requests look the same as those from the browser. Because fiddler links itself as man-in-the-middle proxy between client and server, it also needs to provide a certificate for SSL requests. As this is not recognized as valid certificate, .NET throws an WebException at System.Net.HttpWebRequest.GetResponse() and no traffic shows up in fiddler.

To still be able to check accuracy of the programmatic requests with fiddler, it is possible to directly add a new delegate to ServicePointManager.ServerCertificateValidationCallback which always returns true:

//* Hack for debugging purposes to accept Fiddler certificate
ServicePointManager.ServerCertificateValidationCallback +=
delegate(object sender, X509Certificate cert, X509Chain chain, SslPolicyErrors errors)
{
return true;
};
//*/

// Create request, write post parameters and so on..
HttpWebRequest req = (HttpWebRequest)HttpWebRequest.Create(“https://www.someurl.com”)

http://www.manoli.net/csharpformat/

Remains including the provided csharp.css in the header.php of your current WordPress theme and off you go:

C#

public class OhHai
{
   private string _msg = "oh hai!";

   public void SayHello()
   {
      Console.WriteLine(_msg);
   }
}

Yay! (Almost) like in VS

Update 1.06.2009: Using SyntaxHighlighter Plus instead now.