Posts Tagged ‘solution’

Making solutions with lots of projects load and build faster in Visual Studio

June 1st, 2011 No comments

I came across this great article which talks about simply unloading projects from a solution to make the solution load and build faster in Visual Studio.  This is great, as some of the solution files I work in contain over 300 projects and it can sometimes take a while to load.  Also, because the information about which projects to load is stored in the .suo file (not the .sln file itself), this can be configured per developer so they only have to load the projects that they work in (the .suo files should never be stored in source control).

Now, unloading 300 projects one at a time would take forever, but luckily there the Visual Studio 2010 extension PowerCommands allows us to quickly Load or Unload all of the projects in the solution (or a solution folder) with a couple clicks.  So I typically just unload all of the projects in the solution, and then enable the ones I am working with.

Unload Projects From Solution

The one caveat with this is that because Visual Studio only builds the projects that are loaded, if you get your team’s latest code from source control and then try to build the solution from within visual studio, the build may fail since it will only build the projects you have loaded, and these may depend on changes made to the other projects that you don’t have loaded.  So you can easily reload all of the projects in the solution, build, and then unload all the ones you don’t want again, or what I prefer to do is simply build the solution from MSBuild, as this ignores the .suo file and builds all projects referenced in the .sln file.  I often build my solution files from MSBuild anyways since it has the added benefit of not locking up my visual studio UI while building :).

Happy Coding!

Friendly visual studio solution names for working with multiple branches

April 29th, 2011 7 comments

If you have the latest version of the Visual Studio 2010 extension VSCommands you can give your solutions friendly names that display in the window’s title bar.  This is nice when you are working in different branches, so that you can differentiate which solution you are actually looking at.  I wrote the following regex to put the Branch Name after the Solution name, so for example if you have the client solution open in both Dev and Release, one will be called “Client.sln – Dev” and the other “Client.sln – Release”.

To use this, in Visual Studio go to Tools -> Options -> VSCommands 2010-> IDE Enhancements and then paste in the following (without the quotes):

Friendly Name: “{solutionName} – {branchName}”

Friendly Name – Solution Path Regex: “.*\(?<branchName>.*)\(?<solutionName>.*(?:.sln))”



Happy coding!

— Update —

Here is the new regex that I prefer to use instead now which shows the directories that the solution is sitting in:

Friendly Name: “{solutionName} – {dir1}{dir2}{dir3}”

Regex: “.*\(?<dir1>.*)\(?<dir2>.*)\(?<dir3>.*)\(?<solutionName>.*(.sln)Z)”

— Update 2 for VS 2012 —

These are the settings that I like to use for VS Commands 11 for VS 2012:

Branch Name Regex: “.*\(?<dir1>.*)\(?<dir2>.*)\(?<branchDirectoryName>.*)\(?<solutionFileName>.*(.sln)Z)”

Branch Name Pattern: “{branchDirectoryName} Branch”

Git Branch Name Pattern: “{git:head} Branch”

Main Window Title Pattern: “{solutionFileName} – {dir1}{dir2}{branchDirectoryName} ({sln:activeConfig}|{sln:activePlatform})”

Solution Explorer Window Title Pattern: “ – {solutionFileName} • {vsc:branchName}”

Solution won’t build on TFS Build Server

April 17th, 2011 1 comment

So if you are able to build (compile) the solution on your local machine, but it won’t build on the TFS build server and you are getting an error message similar to:

1 error(s), 1 warning(s)
$/TeamProject/Dev/RQ4/FBs/4.1.4_eSec/RQ4.Client.sln – 1 error(s), 1 warning(s), View Log File
IntegrationfrmGetIntegrationAuthorization.xaml.cs (1138): The type or namespace name ‘BillingFields’ could not be found (are you missing a using directive or an assembly reference?)
C:WindowsMicrosoft.NETFramework64v4.0.30319Microsoft.Common.targets (1360): Could not resolve this reference. Could not locate the assembly "IQ.Core.Resources, Version=, Culture=neutral, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.

Then the problem is likely one of the following:


1 – The project/dll being reference is set to "Specific Version", so open the reference’s properties and change it to "Any Version".


2 – The project is not set to be built under the specific configuration.  Right click on the solution in the Solution Explorer, and choose Configuration Manager.  All projects should be set to be build (i.e. have a checkmark), and all of their platforms should be set to the same value.  Change the Active Solution Platform to the platform you use and ensure that all projects are still set to always build.


3 – The path to the refenced project/dll is too long.  Windows/.NET has a limitation where the reference path cannot be more than 260 characters, and the directory it’s in cannot be more than 248 characters.  So the work around for this is usually to rename your build definition to something shorter, or if you just added a new project/namespace to the project, to shorten its name so the path stays under the limit.

Categories: Build, TFS Tags: , , , ,