Since it’s my vacation I have some more time to work on my home project. I’m creating a web shop in ASP.NET MVC 3 and I’ve got a test TFS server running. I use this project to get some hands on experience in ASP.NET MVC 3 since the project I’m working on is still Webforms but I see more future in MVC. I’ve implemented a basic site where you get a view a list of products and some more details about them.
So my next step is that I want a CI build on the TFS server. I configured it and it seems pretty easy, but than I got the following error in my CI build (but I did not get it when building locally): “/temp/global.asax(1,0): error ASPPARSE: Could not load type …..”.
Eventually I found the problem. In the log file I saw the call to aspnet_compile, which is triggered because I set the property to build the views (MvcBuildViews). The problem is with the path which is supplied to the aspnet_compile command. I eventually fixed it by adding a condition to the AspNetCompiler build task in my web application project file. It now looks like this:
<Target Name="MvcBuildViews" AfterTargets="AfterBuild" Condition="'$(MvcBuildViews)'=='true'">
<AspNetCompiler VirtualPath="temp" PhysicalPath="$(ProjectDir)" Condition="'$(IsDesktopBuild)' == 'true'" />
<AspNetCompiler VirtualPath="temp" PhysicalPath="$(OutDir)\_PublishedWebsites\$(ProjectName)" Condition="'$(IsDesktopBuild)' == ''" />
To get this working I defined a build property IsDektopBuild which I set to true in the Debug build configuration, which is the configuration I’ll build locally. I also defined a Debug CI configuration which does not contain this build property. Now I’ve got my CI build up and running. Next step is to add some specflow acceptance tests to see if they help me with controlling the quality of the code.
In TFS 2010 beta 2 Web Access I created a bug. Nothing fancy there. Next I wanted to add some implementing tasks to the bug, for two reasons:
- The bug was large and I could split it up in some completely independent tasks
- For my iteration backlog worksheet and my burndown reports to function properly I also want to see the progress in hours. Bugs can only have story points and no actual hours.
I would expect this to be nothing strange. I created my bug, navigated to the ‘all links’ tab and clicked Add -> Child. But then, I could only add an existing workitem. Bummer no 1.
I decided to save the bug, then create the task independently and add it the bug as parent to the task. So filled the details of the task and navigated to the Implementation tab and clicked on Add -> Parent, I clicked Browse and then in the popup, I noticed something strange:
Now why was that??? I immediatly checked in Visual Studio to see if it’s possible there to do this, but it’s no problem there.
Now wonder if this is a bug or ‘As Designed’. Anybody else found something a bit inconsequent like this?
I’ve got a small server at home where I also run TFS on for my personal projects and for playing around with it to try some stuff.
Since TFS 2010 Beta 2 is available I wanted to work with VS2010 and TFS 2010. As I’m just a geek who wants to play around with it at home, I didn’t plan how to do this change etc. Because I didn’t care much about the history in source control, I decided to simply reinstall my server (I was already planning to do this as I wanted to use SQL Server 2008).
All went pretty well when installing and configuring. But then yesterday I wanted to add all the source I had on my local machine to the source control. And then the probleem started.
I got the message stating that I already had a workspace mapping for the local directory. WOOPS…. And I couldn’t connect to my old TFS server anymore because I destroyed that completely .
So I hadn’t got a clue what to do, because for as far as I know, the workspace mappings were registered at the server, not locally. I already removed the source control bindings from the solution, but that was not enough. Still getting the error.
It took me quite some time to find that the workspace mappings are also cached on your local machine. I finally found the mapping mentioned in the folder C:\Users\[USER]\AppData\Local\Microsoft\Team Foundation\2.0\Cache\versioncontrol.config. I deleted it from there and I could finally add my source to source control again.
Lesson learned: Think twice before doing a format on my server and try to do some planning / impact analysis before throwing things away, even when I do it on my ‘playing around environment’.
Edit: this is the location on a Windows XP machine: C:\Documents and Settings\[USER]\Local Settings\Application Data\Microsoft\Team Foundation\2.0\Cache