Charles wrote:I'm about to retire for the evening, so I don't have the time to research this right now
sure there is no hurry
Charles wrote:but do you know how msbuild gets those references to C#? Is there a "full name" format that the C# compiler can take?
MsBuild Is using its toolchain utilities which are located in assembly
for .net 4.0 and similarly for other versions
C:\Windows\Microsoft.Net\assembly\GAC_MSIL\Microsoft.Build.Utilities.v4.0\v4.0_4.0.0.0__b03f5f7f11d50a3a\Microsoft.Build.Utilities.v4.0.dll
- Code: Select all
// Microsoft.Build.Utilities.ToolLocationHelper
/// <summary>Gets a fully qualified path to the .NET Framework root directory.</summary>
/// <returns>A string containing the fully qualified path to the .NET Framework root directory, or a null reference (Nothing in Visual Basic) if the targeted version of the .NET Framework is not installed.</returns>
/// <param name="version">The version of the .NET Framework to target.</param>
[TargetedPatchingOptOut("Performance critical to inline this type of method across NGen image boundaries")]
public static string GetPathToDotNetFramework(TargetDotNetFrameworkVersion version)
{
}
// Microsoft.Build.Utilities.ToolLocationHelper
/// <summary>Returns the paths to the reference assemblies location for the given target framework. This method will assume the requested ReferenceAssemblyRoot path will be the ProgramFiles directory specified by Environment.SpecialFolder.ProgramFiles In additon when the .NETFramework or .NET Framework targetFrameworkIdentifiers are seen and targetFrameworkVersion is 2.0, 3.0, 3.5 or 4.0 we will return the correctly chained reference assembly paths for the legacy .NET Framework versions. This chaining will use the existing GetPathToDotNetFrameworkReferenceAssemblies to build up the list of reference assembly paths.</summary>
/// <returns>Collection of reference assembly locations.</returns>
/// <param name="targetFrameworkIdentifier">Identifier being targeted</param>
/// <param name="targetFrameworkVersion">Version being targeted</param>
/// <param name="targetFrameworkProfile">Profile being targeted</param>
/// <exception cref="T:System.ArgumentNullException">When the frameworkName is null</exception>
public static IList<string> GetPathToReferenceAssemblies(string targetFrameworkIdentifier, string targetFrameworkVersion, string targetFrameworkProfile)
{
}
and similar functions there are a lot of GetPath functions in this Class
MsBuild is calling such functionalities like this is Microsoft.Common.Targets
- Code: Select all
<PropertyGroup>
<TargetFrameworkMoniker Condition="'$(TargetFrameworkMoniker)' == '' and '$(TargetFrameworkProfile)' != ''">$(TargetFrameworkIdentifier),Version=$(TargetFrameworkVersion),Profile=$(TargetFrameworkProfile)</TargetFrameworkMoniker>
<TargetFrameworkMoniker Condition="'$(TargetFrameworkMoniker)' == ''">$(TargetFrameworkIdentifier),Version=$(TargetFrameworkVersion)</TargetFrameworkMoniker>
<!-- The FrameworkPathOverride is required for the inproc visual basic compiler to initialize when targeting target frameworks less than 4.0. If .net 2.0 is not installed then the property value above will not provide the location
of mscorlib. This is also true if the build author overrides this property to some other directory which does not contain mscorlib.dll. In the case we cannot find mscorlib.dll at the correct location
we need to find a directory which does contain mscorlib to allow the inproc compiler to initialize and give us the chance to show certain dialogs in the IDE (which only happen after initialization).-->
<FrameworkPathOverride Condition="'$(FrameworkPathOverride)' == ''">$([Microsoft.Build.Utilities.ToolLocationHelper]::GetPathToStandardLibraries($(TargetFrameworkIdentifier), $(TargetFrameworkVersion), $(TargetFrameworkProfile)))</FrameworkPathOverride>
<FrameworkPathOverride Condition="!Exists('$(FrameworkPathOverride)\mscorlib.dll')">$(MSBuildToolsPath)</FrameworkPathOverride>
</PropertyGroup>
<FrameworkPathOverride Condition="'$(FrameworkPathOverride)' == ''">$([Microsoft.Build.Utilities.ToolLocationHelper]::GetPathToStandardLibraries($(TargetFrameworkIdentifier), $(TargetFrameworkVersion), $(TargetFrameworkProfile)))</FrameworkPathOverride>
<FrameworkPathOverride Condition="!Exists('$(FrameworkPathOverride)\mscorlib.dll')">$(MSBuildToolsPath)</FrameworkPathOverride>this bold is from above code snippet because i dont know how to Bold when wrapped in code tags
now while building Msbuild is using above mentioned features and presenting info like
Primary reference "System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089".
Resolved file path is "C:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.Core.dll".
Reference found at search path location "{TargetFrameworkDirectory}".
For SearchPath "{TargetFrameworkDirectory}".
Considered "C:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.Core.exe", but it didn't exist.
This reference is not "CopyLocal" because it's a prerequisite file.
Done executing task "ResolveAssemblyReference".
.after resolving paths Msbuild is passing info to C# compiler like this
/reference:"C:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.Core.dll" which is a absolute path now compiler will have no confusion
whereas Cobras -ref:- does not allow including paths
either expand -ref:- to include paths or introduce -refStrict:- or refWithPath:- for this to work.
or am i missing something very obvious in Cobra that i have overlooked
.net 4.0 does allow using
multiple version assemblies and sooner or later
users of cobra might use this feature. or hit a wall working on external projects.
resolving path and all i can take care of in my .cobraproj file give me a switch to
specify path of assembly explicitly
Thanking_You
RIGHT_THEN