Share via

Assembly Resolution in MSBuild and Visual Studio Series Introduction

  • Article

Assembly references are an integral part of build process. When the assembly references passed to the compiler are correct everything works but when they are not projects stop building. When this happens It can be frustrating to try and figure out why a reference was resolved from one location rather than another thereby causing the problem. In this series we will be detailing what steps are taken to take a reference from the project file and turn it into the path on disk that is passed to the compilers.

This series will be focusing on the MSBuild task ResolveAssemblyReference. This task does the work of taking references declared in project files and turning them into paths on disk.

The reason we discuss this task is because this same task is used by both MSBuild on the commandline and Visual Studio to find the references. Internally Visual Studio uses MSBuild as its build engine, so even though this series focuses on the behavior in MSBuild, it behaves exactly the same way in Visual Studio.

Outline for the of the assembly resolution series.

Part 1

In part one we will discuss how references are represented inside of the project file. This will give a basic understanding when looking at a project file of the different forms a reference can take (e.g. file path, simple name, or fusion name) and the additional attributes that can be set on those references.

Part 2

In part two we will discuss some of the basic inputs to the ResolveAssemblyReference task. Why these inputs are important and how they affect how references are found is outlined. This post also goes into detail about how a reference is resolved and the different kinds of algorithms involved in turning what is represented in the project file into a path on disk.

Part 3

In part three we discuss the AssemblyFoldersEx registry location. This is just one of the places where references can be resolved from, however it is one of the most complicated locations due to how the location is searched. This section will discuss the layout of the registry keys and the algorithms used to find assemblies which are declared in this location.

Part 4

In part four we will discuss how conflicts between dependent assemblies arise and how they are dealt with. This section will provide an understanding of why conflict warnings occur and how they can be prevented or disabled. This part also discusses how the determination as to whether or not an assembly should be copied to the output directory is made. This is partially dependent on the resolution of conflicts between dependent assemblies and for this reason is in the same section.

Part 5

In part five we will discuss how the target framework moniker represented in the project file is used to generate a list of directories which represent the framework that the project is targeting. We also discuss the new multi-targeting rules that were introduced in MSBuild 4.0 to prevent users from referencing framework assemblies which are not part of the framework their project is targeting.

Part 6

In part six we will discuss the ResolveAssemblyReference task logging output. It logs a large amount of information about why it resolves references a certain way. This information is very useful when trying to determine why a reference was not resolved when it was expected to resolve or why one reference was picked from a certain location when it was expected to come from another.

Chris Mann – Developer, MSBuild

Comments

  • Anonymous
    May 27, 2010
    MsBuild Pros -- Please help. Speaking of Assembly References, do you happen to know why I keep getting this... Considered "C:Program FilesReference AssembliesMicrosoftFrameworkv3.5System.Configuration.exe", but it didn't exist. Considered "C:Program FilesReference AssembliesMicrosoftFrameworkv3.5System.Configuration.dll", but it didn't exist. Considered "C:Program FilesReference AssembliesMicrosoftFrameworkv3.0System.Configuration.exe", but it didn't exist. Considered "C:Program FilesReference AssembliesMicrosoftFrameworkv3.0System.Configuration.dll", but it didn't exist. Considered "C:WINDOWSMicrosoft.NETFrameworkv3.5System.Configuration.exe", but it didn't exist. Considered "C:WINDOWSMicrosoft.NETFrameworkv3.5System.Configuration.dll", but it didn't exist. Considered "C:WINDOWSMicrosoft.NETFrameworkv3.0System.Configuration.exe", but it didn't exist. Considered "C:WINDOWSMicrosoft.NETFrameworkv3.0System.Configuration.dll", but it didn't exist. Considered "C:WINDOWSMicrosoft.NETFrameworkv2.0.50727System.Configuration.exe", but it didn't exist. ...when my machine is fully-patched and the Solution is very simple, with 1 Web Application project and 1 Web Deployment project, in Visual Studio 2008 Standard, on Windows XP Pro, with Framework 3.5 being used? I discuss the whole matter here... forums.asp.net/.../1548089.aspx ...but there seems to be no way to fix this matter and Visual Studio reports both "Build Succeeded And Rebuild All Failed" at the same time. What do you think? Please advise. Thank you. -- Mark Kamoski

  • Anonymous
    March 17, 2011
    I really want to see this post now.  Did you finish this series somewhere else? -Ryan

  • Anonymous
    March 25, 2011
    I'd also like to have a look at the complete series. Where can i?