Who would have thought!
I have been doing some serious modifications to our build libraries and I modified all sorts of parameters. I used to set the msbuild property <OutDir>C:lol</OutDir> before the call to main project imports, however with the fantastic introduction of MSBuild 4 now there is the ability for targets to specify ‘BeforeTargets’ and ‘AfterTargets’. This means no longer is it required to mess around with properties in the common targets (BeforeBuildDependsOn) that rudely does NOT care about what is set before it came along.
So I try and achieve the goal of my target being able to included anywhere in the project. This works mostly fine but setting OutDir after common means there are a few properties which are wrongly set such as TargetDir and Target Path.
<TargetDir Condition="'$(OutDir)' != ''">$([MSBuild]::Escape($([System.IO.Path]::GetFullPath(`$([System.IO.Path]::Combine(`$(MSBuildProjectDirectory)`, `$(OutDir)`))`))))</TargetDir>
<TargetPath Condition=" '$(TargetPath)' == '' ">$(TargetDir)$(TargetFileName)</TargetPath>
This meant my wix project was now pointing to the wrong location for the TargetDir and TargetPath variables. So I add in the code to also modify TargetDir when OutDir is changed and wix does not care.
On further invesigation i hardcoded TargetPath to ‘C:ILikeCheeselolrofl.proj’ and even though TargetDir was something sensible wix would still assume targetpath was C:ILikeCheese.
Realistically, TargetDir property is used so little that It should be on the way out yet is still used so critically in Wix and in DesignTimeResolveAssemblyReferences .
Conclusion is that you can not trust the build system to be simple!
Our work product is a bit unique in regard to how our pages are coded. Due to the high amount of inheritance in our pages we implemented all the pages in class files which inherit Web.UI.Page and just had .aspx page stubs which pointed the code behind to this class. This worked well until we hit the annoying issue of having to synchronize the aspx files between resources, and making sure they pointed to the right level down the inheritance chain. A messy solution was presented which was hard to maintain, so I did a bit of research and by using a HttpHandler I found we could solve our problem by keeping all pages inside the dll itself.
I have included the code for the concept below and a small sample of how its used.
Continue reading HttpHandler loading Web.UI.Page classes without .aspx files
I was tinkering around with sending files across a web site at work and found this article by
It covers the setting of the Mime Type, changing the file name that comes across and forcing it to appear as a pop up.
Continue reading HTTP Headers in Asp.net to alter the transfer of files
The night after my first failed upgrade I kicked off another attempt.
This time I was to install Service Pack 1 for Visual Studio 2008 before installing the service pack for Team Foundation Server. A few problems I came across:
Continue reading TFS 2008 SP1 Upgrade Part 2 – Error TF30059: Fatal error while initializing web service from server
It’s 1AM, you’ve just completed a TFS 2008 upgrade to SP 1 and for a test you just performed a ‘Get Latest’ on a project tree.
‘The server returned content type , which is not supported’
Well, that doesn’t sound good. Skim reading TFSInstall-SP1-RTM-v080908.chm shows nothing about this. Just before pressing the panic button you do one last thing. Google it.
Thankfully I came across a post to a problem which is both similar and different on the MSDN Fourms.
Continue reading TFS 2008 SP1 Upgrade – The server returned content type , which is not supported
Across the years you tend to accumulate a series of tools through day to day computer use. This of course starts when you have little or no money so feature rich applications which are free/unrestricted are an important part of your collection. I have summed up my collection of tools below and links to where you can get them. One of my favourite sources is the beloved source forge.
Continue reading Poor Coder Tools