The solutions in the project I’m working on are quite big and can easily take up 30 to 90 seconds to build, even though we have rather fast laptops. This is probably because of some build-plugins we are forced to use and the tight SharePoint integration of those plugins. Nevertheless, it’s quite annoying to see Visual Studio ‘hang’ every time you build your solution.

Last week I had some time on my hands to do some research on how we could improve these long builds. Turns out you can call MSBuild directly and let your solution compile outside of the Visual Studio instance. The build will still take up about the same amount of time, but it’s less annoying as you can still do some work in Visual Studio.

I’ve used Scott Hanselman’s blogpost to create some new External Tools in Visual Studio, placed them in my Menu and created keyboard shortcuts for them.

At the moment I’ve got 3 new items in my menu to build my complete solution, clean my complete solution and to build the project I’m currently working in.

clip_image001

The ‘Clean Solution’ button bound to the default out-of-the-box functionality, offered by Visual Studio.

The External Tool ‘Solution (MSBuild)’ is configured like so:

Title: MSBuild
Command: C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe
Arguments: $(SolutionFileName) /m:3 /p:BuildInParallel=true /v:m /p:WarningLevel=0 /p:Configuration=Debug
Initial directory: $(SolutionDir)

The ‘Current Project (MSBuild)’ is implemented like this:

De 'External tool' achter de optie Current Project (MSBuild)is als volgt:

Title: MSBuild Project
Command: C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe
Arguments: $(ProjectFileName) /v:m /p:WarningLevel=0 /p:Configuration=Debug
Initial directory: $(ProjectDir)

For both ‘tools’ I’ve set ‘Use Output Window’ to true.

What you are doing here is telling to do use 3 cores (/m:3), build the projects in parallel (/p:BuildInParallel=true (default)), use minimal logging (/v:m), ignore warnings (/p:WarningLevel=0) and use the debug configuration (/p:Configuration=Debug).

You can also add keyboard shortcuts to the options, this can be done in the screen below.

image

Disclaimer: copy-paste image of Scott Hanselman’s post

As Scott already mentions in his post, errors aren’t listed in the Error List of Visual Studio, but in the Output Window. If you’ve got a lot of errors, this can be quite annoying.

One other gotcha is the post-build step which is configured in some projects. We’ve got several projects which have post-build steps doing stuff, like aspnet_merge to merge all the usercontrols in the dll’s. This didn’t work anymore.

Apparently, this option, When the build updates the project output, doesn’t work properly with MSBuild:

image

You have to set it to On successful buildin order to run the post-build steps.

image

After having configured this, you are good to go and able to enjoy a responsive Visual Studio again. Also note, we are still working in Visual Studio 2008. It is said performance is a lot better in Visual Studio 2010 and Visual Studio 2012, but I haven’t used these products on this project yet, so I’m not sure about that.

There are also some other Visual Studio performance tuning tips, James Lewis has summed some of them up in a blogpost.

Because of a failing hard drive I had to re-install my Windows installation, including cloning all of my BitBucket repositories back to my projects folder.

Getting all the solutions back on the local development machine is very easy, but after opening, I discovered they couldn’t be build anymore. The reason for this: several references were missing. This wasn’t that strange at all, because these references were libraries pulled pulled down via NuGet and not pushed into the repository.

I had suspected there was something in NuGet which would make it easy to download the referenced packages. Reason for me to expect this is the packages.config file which is created after pulling down NuGet packages. This file contains all the information needed to re-download them, you see?

<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="FluentAssertions" version="1.7.1.1" />
  <package id="Moq" version="4.0.10827" />
</packages>

At the moment there isn’t an option (i.e.: I couldn’t find it) to re-download the referenced libraries in the NuGet package manager. After doing a bit more research on the matter I discovered a page in the NuGet documentation called ‘Using NuGet without committing packages to source control’.

Over there they tell you to use the ‘Enable NuGet Package Restore’-option, which is available after right-clicking on the solution file.

Enable NuGet Package Restore Context Menu item

So, this is what I did and it kind of worked. This adds a new solution folder with the name .nuget and a nice NuGet executable.

New Solution folder with package restore files

An important note: Make sure you don’t have too much projects loaded in the solution. I’ve tried this option in my Orchard solution with several projects of my own and was confronted with several Internal Server Errors 500 (time outs). After I made sure just my own custom projects were loaded and all other Orchard projects were unloaded, this option worked like a charm.

When building the solution, the libraries should get automatically downloaded and installed in the corresponding packages folder.
Well, I must have done something wrong when I added the references in the past (via an old NuGet console), because the libraries weren’t placed in the (correct) packages folder.

Lucky for me, the newly added NuGet executable can be started via a command prompt also and it takes several startup parameters. The complete list (for the current version):

NuGet Version: 1.7.30402.9028
usage: NuGet  [args] [options]
Type 'NuGet help ' for help on a specific command.

Available commands:

 delete      Deletes a package from the server.
 help (?)    Displays general help information and help information about other
             commands.
 install     Installs a package using the specified sources. If no sources are
             specified, all sources defined in %AppData%\NuGet\NuGet.config are
             used.  If NuGet.config specifies no sources, uses the default NuGe
             t feed.
 list        Displays a list of packages from a given source. If no sources are
             specified, all sources defined in %AppData%\NuGet\NuGet.config are
             used. If NuGet.config specifies no sources, uses the default NuGet
             feed.
 pack        Creates a NuGet package based on the specified nuspec or project f
             ile.
 publish     Publishes a package that was uploaded to the server but not added
             to the feed.
 push        Pushes a package to the server and optionally publishes it.
 setApiKey   Saves an API key for a given server URL. When no URL is provided A
             PI key is saved for the NuGet gallery.
 sources     Provides the ability to manage list of sources located in  %AppDat
             a%\NuGet\NuGet.config
 spec        Generates a nuspec for a new package. If this command is run in th
             e same folder as a project file (.csproj, .vbproj, .fsproj), it wi
             ll create a tokenized nuspec file.
 update      Update packages to latest available versions. This command also up
             dates NuGet.exe itself.

For more information, visit http://docs.nuget.org/docs/reference/command-line-re
ference

As I only need to install the packages which are specified in the auto-generated packages.config. To do this, the following command can be used from within the command prompt:

nuget i ..\MvcApplication3\packages.config -o ..\Packages

This will install the packages in the Packages folder on the same level as the project folder and your folder structure will look like this:

image

After having executed this command I was finally able to do a successful build again.

It takes a bit of research, but in the end everything will work. I guess these issues will get resolved in future releases of NuGet, but for now this workaround will work.

Aan mij was de taak om een applicatie te schrijven welke informatie van SharePoint (Wiki sites) website kon wegschrijven naar HTML bestanden met een bepaalde opmaak.

Niks aan de hand, ware het niet dat ik op m’n Windows 2008 VM zowel MOSS 2007 als Visual Studio 2010 had geïnstalleerd. Bij het toevoegen van de benodigde references kwam ik er ineens achter dat ik de SharePoint 2007 DLL’s niet kon vinden in de lijst. Het is ook een bekend ‘probleem’, aangezien het ook op Connect staat geregistreerd als issue. Er staat ook dat het probleem is geëscaleerd naar het betreffende team, maar dat was al op 20 november 2009. Jammer dat dergelijke calls dan niet verder worden bijgewerkt, want blijkbaar is het antwoord gewoon ‘zoek het lekker zelf uit’.

Gelukkig kan ik dat ook prima zelf uitzoeken.
De dll’s staan namelijk gewoon in de map C:\Program Files\Common Files\Microsoft Shared\Web Server Extenstions\12\ISAPI. Door de Browse knop te gebruiken bij het Add Reference scherm kan dan gewoon, net als vroeger, de betreffende dll worden geselecteerd, bijvoorbeeld Microsoft.SharePoint.dll.

Het werkt dan allemaal prima, maar is wel jammer dat dit niet standaard wordt ondersteund. Het is al erg genoeg dat we met Visual Studio 2008 ook al niet met SharePoint 2010 kunnen werken.

Onlangs liep ik weer tegen het probleem aan dat ik de PublicKeyToken van m'n gegenereerde assembly moest zien te vinden. Er zijn natuurlijk verschillende mogelijkheden om hier achter te komen, maar de mooiste is toch wel de tip van Jeremia Clark. Op z'n weblog heeft hij beschreven hoe hij de token krijgt door middel van het aanmaken van een nieuw External Tools commando, de link: http://blogs.msdn.com/b/miah/archive/2008/02/19/visual-studio-tip-get-public-key-token-for-a-stong-named-assembly.aspx

Het is dus de bedoeling om een nieuw commando te maken welke sn.exe oproept.

Als argument wordt er dan –T $(TargetPath) opgegeven.

Nog even het vinkje aan zetten dat de waarde in de Output window moet komen en klaar is het. Nu kun je vanuit het Tools menu heel snel de Public Key Token achterhalen.

Ik had in VS2010b2 een probleem dat er bij javascript geen IntelliSense verscheen. Na het melden van deze bug bij MS Connect hebben ze het geregistreerd en met een tijdelijke workaround gekomen. Wat blijkt, als je de target wijzigt in bijvoorbeeld XHTML1.1 krijg je gelijk IntelliSense die je wilt. Wat ook wordt aangeraden is om al je settings te resetten. Op zich kan dat wel natuurlijk, maar dat is niet echt ideaal. Hier gaan ze er op verder: http://blogs.msdn.com/webdevtools/archive/2009/10/23/visual-studio-2010-beta-2-intellisense-issue-in-javascript-html.aspx Komt er dus op neer dat je bij de 'Import and Export' wizard je settings moet resetten en dan voor Web Development moet kiezen als standaard ontwikkel view. Op zich is dit natuurlijk niet echt een super oplossing, maar ik vind het wel gaaf om te zien dat er echt iets wordt gedaan met de meldingen van het beta product. Zal binnenkort wat intensiever bezig gaan met VS2010 om te kijken of ik nog wat meer kan vinden.