I have created a C# .Net Standard library which references two Windows SDK libraries.
The references are
C:\Program Files (x86)\Windows Kits\10\References\10.0.16299.0\Windows.Foundation.FoundationContract\3.0.0.0\Windows.Foundation.FoundationContract.winmd
C:\Program Files (x86)\Windows Kits\10\References\10.0.16299.0\Windows.Foundation.UniversalApiContract\5.0.0.0\Windows.Foundation.UniversalApiContract.winmd
This works on my local dev machine.
VS Team Services build first shows the following warning:
2018-06-13T01:17:22.3393846Z ##[warning]C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2106,5): Warning MSB3245: Could not resolve this reference. Could not locate the assembly "Windows.Foundation.FoundationContract". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
Later it fails with the following error:
Error CS0246: The type or namespace name 'Windows' could not be found (are you missing a using directive or an assembly reference?)
Naively, I thought I just have to set Copy Local to True in Visual Studio to true and everything will be fine. I was wrong.
Question
How to, in VSTS, build projects which reference SDK winmd files?
Refer to these steps to deal with this issue:
Right click the project in Visual Studio > Edit {project name}
Replace the relative paths of these assemblies to absolute paths
Sample code:
<ItemGroup>
<Reference Include="Windows.Foundation.FoundationContract">
<HintPath>C:\Program Files (x86)\Windows Kits\10\References\10.0.16299.0\Windows.Foundation.FoundationContract\3.0.0.0\Windows.Foundation.FoundationContract.winmd</HintPath>
<IsWinMDFile>true</IsWinMDFile>
</Reference>
<Reference Include="Windows.Foundation.UniversalApiContract">
<HintPath>C:\Program Files (x86)\Windows Kits\10\References\10.0.16299.0\Windows.Foundation.UniversalApiContract\5.0.0.0\Windows.Foundation.UniversalApiContract.winmd</HintPath>
<IsWinMDFile>true</IsWinMDFile>
</Reference>
</ItemGroup>
Related
I cloned a solution from Git to my computer. For this solution, we use a SDK. This SDK is placed at the same path in all of contributors computers. I cannot build projects which have assembly references, they are failing to get that files and create classes from that reference. They are using the SDK. Project's assembly references gets its DLLs from a common path which is specified at the environment variable.
Projects are written in .NET 5.
Code is like below;
<Reference Include="MyDLL">
<HintPath>$(MYSDK)\bin\MyDLL.dll</HintPath>
</Reference>
and error list is filled errors like below;
Error CS0246 The type or namespace name 'Engine' could not be found (are you missing a using directive or an assembly reference?)
I have two projects under the same solution that both rely on `System.Net.Http' as a dependency. The strange thing is that both projects use different physical dll files, which is causing a runtime MissingMethodException error when trying to run unit tests.
library project uses:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.Net.Http.dll
test project uses:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\System.Net.Http.dll
Why are there two instances of the assembly and how can I force VS to use a specific instance? The csproj files do not specify a specific file path:
<Reference Include="System.Net.Http" />
The only thing I can think of is I used the built in "Create Unit Tests" option when right-clicking the method in the library project. I'm guessing this loads a default set of references which does not match when you create a new project.
I faced some issues regarding adding an external assembly (.dll) to my .NET Core 2.0 console application on Visual Studio Code as there are little to none documentation about how you can do it.
Microsoft provides a very good tutorial about how one can add NuGet Packages and Project to project references, but no information on how to add external dlls.
After some research I managed to get it working.
Open your .csproj file
Below </PropertyGroup> tag, add
<ItemGroup>
<Reference Include="Your dll file name">
<HintPath>Your dll file name.dll</HintPath>
<SpecificVersion>False</SpecificVersion>
<!-- You may set it to true if your dll has a specific version -->
</Reference>
</ItemGroup>
Move the dll to the root folder of your project (where Program.cs is)
Navigate to the root folder of your project using console/terminal and execute dotnet restore to import all the references
Then, execute dotnet run
Do not remove the dll from your root folder. If you do, you will receive the following error:
error CS0246: The type or namespace name 'Your dll File' could not be found (are you missing a using directive or an assembly reference?)
Right click project
Add existing item > select path to .dll
After added dll in project,right click .dll
build-action = Content, Copy-to-output-dir = Always/ or if newer
Visual Studio Community 2019 [v16.8.4]
Right click your aspnetcore project
Project Reference... > Browse > Browse...
Locate and Add your DLL file
On Windows 7 with .NET 4.5.2 installed, I create a new ClassLibrary project targetting .NET 4.5.2.
I want to calculate the code metrics for that assembly by launching the metrics.exe that is shipped with FxCop with Visual Studio 2013 located in c:\Program Files (x86)\Microsoft Visual Studio 12.0\Team Tools\Static Analysis Tools\FxCop\.
Everything works fine.
I then nuget System.Collections.Immutable v1.1.37.
I can see in the references that only System.Collections.Immutable is referenced since the other dependencies (System.Runtime, System.Collections, System.Diagnotics.Debug etc.) are found (I suppose in c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.2\Facades\)
I create a dummy method that creates a dummy ImmutableArray var foo = new List<int>().ToImmutableArray();
Everything compiles and works just fine.
I relaunch the metrics computation.
I have the following error:
metrics.exe /f:c:\dev\ClassLibrary1\ClassLibrary1\bin\Debug\ClassLibrary1.dll /o:toto.xml
error : CA0055 : Could not load file:
'c:\dev\ClassLibrary1\ClassLibrary1\bin\Debug\ClassLibrary1.dll'.
If I perform the same command on the System.Immutable.Collections assembly, I have the following error:
Calculating metrics for file 'c:\dev\ClassLibrary1\ClassLibrary1\bin\Debug\System.Collections.Immutable.dll'.
Could not locate the framework assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
Now, if I copy the System.Runtime file located in c:\Windows\Microsoft.NET\Framework\v4.0.30319\ in the output directory, calculating the code metrics on ClassLibrary1.dll works fine. But if I copy the version that is in c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.2\Facades\, if fails again.
When debugging another library using Immutable in a web application, I can see the following in the "Loaded modules":
System.Runtime.dll C:\windows\Microsoft.Net\assembly\GAC_MSIL\System.Runtime\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Runtime.dll Yes No Skipped loading symbols. 544 4.06.1055.0 06/11/2015 03:49 000007FED10D0000-000007FED10D9000 [15760] w3wp.exe [4] /LM/W3SVC/2/ROOT/WebSite-2-131026947404276669
All of this makes me think that System.Collections.Immutable uses the version of System.Runtime that is in c:\Windows\Microsoft.NET\Framework\v4.0.30319\
So I thought, "let's add an explicit reference to that assembly." If I do, I got the following compilation error:
error CS1703: Multiple assemblies with equivalent identity have been imported: 'c:\Windows\Microsoft.NET\Framework\v4.0.30319\System.Runtime.dll' and 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5.2\Facades\System.Runtime.dll'. Remove one of the duplicate references.
There something somewhere that is wrong and I can't pinpoint it.
I worked around the error by using the /ignoreinvalidtargets for metrics.exe.
Does anyone have a club about the real error?
(I also tried targetting .NET Framework 4 and adding references to all the dependant assemblies from c:\Windows\Microsoft.NET\Framework\v4.0.30319\ with CopyLocal = true. It works, despite the following warning:
Some NuGet packages were installed using a target framework different from the current target framework and may need to be reinstalled. Visit http://docs.nuget.org/docs/workflows/reinstalling-packages for more information. Packages affected: System.Collections, System.Collections.Immutable, System.Diagnostics.Debug, System.Globalization, System.Linq, System.Resources.ResourceManager, System.Runtime, System.Runtime.Extensions, System.Threading
)
Thanks.
I got some strange issue here, have a software that build normally in Visual Studio, all references where added using NuGet, and the Newtonsoft.Json.dll is in the packages folder and also the reference points to that folder.
When building in the build server, we notice test failures and going further we found that the Newtonsoft.Json.dll copyed in fact was the wrong one, from Blend folder.
From build log:
Copying file from "D:\APPS\Microsoft Visual Studio
12.0\Blend\Newtonsoft.Json.dll" to "D:\TB\2\PLWRO-WebPP\WebPP-Main-Dev-CI\bin\Newtonsoft.Json.dll".
To solve it I renamed Newtonsoft.Json.dll from blend folder for another thing, and then the build got to work normally as expected.
My question is, WHYYY?!?!? Seems that the build is looking for references before in the Blend folder and not in the set location in the hint path - see below.
<Reference Include="Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\..\packages\Newtonsoft.Json.7.0.1\lib\net45\Newtonsoft.Json.dll</HintPath>
</Reference>
You could try adding the <private>true</private> element after your HintPath element. This should force the copy to the local directory.
The other part that is interesting, you are looking for an old version (v4.5.0.0) whilst referencing a new version (7.0.1) in your packages.
In Visual Studio, you could try asking Nuget to update the reference to 7.x for this library, and then see if that helps MSBuild pull the library from a more specific location.