I have created a C# test project in VS2015 RC. it builds locally but when i attempt to build on our CI build server (TeamCity) it fails with errors:
UnitTest1.cs(2,17): error CS0234: The type or namespace name
'VisualStudio' does not exist in the namespace 'Microsoft' (are you
missing an assembly reference?)
[... .Tests.csproj]
UnitTest1.cs(9,10): error CS0246: The type or namespace name
'TestMethod' could not be found (are you missing a using directive or
an assembly reference?)
[... .Tests.csproj]
Clearly this is because the assembly containing these namespaces (Microsoft.VisualStudio.QualityTools.UnitTestFramework) is not on the build server; on my local machine it resides at C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll.
I could copy the assembly into my solution so that it becomes part of the codebase but manually moving files feels like a bit of an inelegant hack. I searched around on nuget and found http://www.nuget.org/packages/Microsoft.VisualStudio.QualityTools.UnitTestFramework/ which I figured would do the trick, but installing that package failed with:
Install-Package : Could not install package
'Microsoft.VisualStudio.QualityTools.UnitTestFramework 11.0.50727.1'.
You are trying to install this package into a project that targets
'.NETFramework, Version=v4.5.2', but the package does not contain any
assembly references or content files that are compatible with that
framework
What's my best option of solving this? I'm surprised that creating a test project in VS2015 does not automatically include all the dependencies that I need, though perhaps I'm being naive (I'm something of a fledgling dot netter).
The answer is similar to option 1 in eng.augusto's answer.
Microsoft doesn't provide NuGet for the latest version of Microsoft.VisualStudio.QualityTools.UnitTestFramework,
but rather supplies it as a part of Visual Studio
(normally at C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll)
I created the folder Microsoft.VisualStudio.QualityTools as a subfolder of my solution and copied:
Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll
Microsoft.VisualStudio.QualityTools.UnitTestFramework.xml
The files should be added to source control (even if DLLs are usually ignored).
Then I changed references in my Test.csproj to refer to a new location.
Hmm I have some ideas, so choose the one that best fits your needs
A simple answer should be mark the DLL to copy local and use a folder like Assemblies in the same folder of the solution and references "Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll"
Install Visual Studio in your build server. Sounds nuts but it's the closest to "developer machine" that you have.
Install the DLL in the GAC so you don't have to bother with this.
Fix the NuGet package (Adding a reference for the .NET Framework version) and use it.
Downgrade your .NET Framework version so you can use the NuGet package.
Create your own NuGet server! (and add the reference of the DLLs you need).
IMHO I'd choose the first answer, because it seems to be the "best way" to use NuGet to resolve all your packages problems but you are using a DLL that you don't know if it should be trusted.
In system used in "old" languages like C, or C++ it's common you download the source code and the libraries needed for the code to run so I do not think the NuGet package it's the best solution.
Using the first option you always have the same version and could check the MD5 of the file and know exactly what is running in your build server.
Maybe the real best option should be 6. When you use your own NuGet server to handle your DLLs making your live more awesome and trustable.
For projects created in VS 2017. Adding Nuget package Microsoft.VisualStudio.QualityTools.UnitTestFramework.Updated allows to build unit test projects on CI without VS installed on build server:
I was having this issue when trying to use MSBuild on our dev server via our CI/CD process after I was asked to uninstall VS2013 from our dev server by our IT team.
In my case in my build output there were a few lines with the word Considered. What this means is that the build is considering those folders for locations where the file may be located. One of those lines was as follows:
Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll", but it didn't exist.
I copied Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll from my local machine to that folder on the dev server and the error went away.
Of course Microsoft does a s...t job. To fix this, you need to copy the dll's to some convinint lication and reference them from your ptoject .csproj file.
<HintPath>..\packages\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll</HintPath>
</Reference>
</ItemGroup>
<ItemGroup>
<Reference Include="QualityTools-Fakes">
<HintPath>..\packages\Microsoft.QualityTools.Testing.Fakes.dll</HintPath>
</Reference>
</ItemGroup>
<ItemGroup>
I don't understand why when we add this from VSudio it does not update the same file instead no one has an idea what it does. In Java you have a single file pom.xml or build.gradle, nothing else. In C# there is all sorts of stuff which adds no value but confusion.
Related
I've been fighting with nuget all morning, trying to get a solution that builds in the UI AND from the command line. Here's the latest problem, which I haven't made any headway on:
I'm running nuget restore on the solution file. This works, all referenced packages are restored - I can see the files in the /packages folder under the solution folder.
I'm building with devenv command line - I have to because this solution contains project types that msbuild doesn't support.
The first project that references a nuget package, fails to compile with ...cs(3,7,3,17): error CS0246: The type or namespace name 'Newtonsoft' could not be found (are you missing a using directive or an assembly reference?)
The project builds (and rebuilds, and rebuilds with the package folder cleared out) just fine in the UI, but the command line build isn't seeing the restored packages.
The build that's failing is in a CLEAN folder on the same computer where I'm doing the UI build, so it's get from source control, nuget restore, devenv build.
Things I've tried
Looking for bad hint paths in the project file (saw this in another question/answer). These references don't appear in the project file at all - trying to add them produces an error saying that the reference can't be added because it's already added automatically by the build system.
Verifying that files do exist after restore.
Doing the same steps from a command line in the SAME folder where the UI is building. This works fine.
What am I missing? this shouldn't be so hard..
UPDATE: The solution consists of 14 projects: 9 C# class libraries, 2 c# applications, 1 reporting services project and 2 WiX installer projects. All C# projects target Net472, NOT Core. The key part of the solution structure appears to be:
Project A references
Newtonsoft.Json via nuget
Project B references
Project A
Newtonsoft.Json via nuget
Other packages via nuget
During build, project B fails to compile due to the lack of a reference to Newtonsoft.Json. Project A and all of the other nuget packages are supplied to the compier as references. Again, all nuget packages are in fact restored - Project A finds Newtonsoft.Json, project B does not.
In the detailed msbuild log output, this is the only mention of Newtonsoft.Json in the build of project 10 (Project B above):
10> Dependency "Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed".
10> Resolved file path is "...ProjectA\bin\Release\Newtonsoft.Json.dll".
10> Reference found at search path location "...ProjectA\bin\Release".
10> For SearchPath "...ProjectA\bin\Release".
10> Considered "...ProjectA\bin\Release\Newtonsoft.Json.winmd", but it didn't exist.
10> Required by "...ProjectA\bin\Release\ProjectA.dll".
10> Required by "C:\...ProjectA2\bin\Release\ProjectA2.dll".
10> Found related file "...ProjectA\bin\Release\Newtonsoft.Json.xml".
10> The ImageRuntimeVersion for this reference is "v4.0.30319".
(Folder and project names have been obscured)
A couple things going on here, finally got a solution that works. Why this built in the IDE is anyone's guess - it's adding some extra secret sauce to make things work (more than just the automatic nuget restore).
I tried changing all projects to use PackageRef instead of packages.config. That caused nuget restore to fail with an obscure msbuild error that I didn't try to diagnose.
I noticed that SOME of the nuget packages were referenced in the .csproj files with ordinary Reference elements, but some of them were not (specifically, Newtonsoft.Json in "Project B" - and some others that I hadn't noticed due to B failing).
To correct the situation:
Remove ALL use of PackageRef elements - change back to packages.config in ALL projects
Make sure the each of the nuget -provided DLLs is referenced in the .csproj files. You have to do this by editing the csproj file by hand - the IDE won't let you add the missing references.
I'm assuming that this is a temporary situation and that in the long run the solution will be to use PackageReference everywhere.
you already checked the files app.config and packages.config, and the dotnet framework version?
Nuget package not found after restore VS 2019 16.5.0
devenv /build command line does not have the job to restore nuget packages by default. However, there are such options in VS IDE so that it will restore packages first and then build. But these do not work in command line.See this similar issue.
But you still want to use devenv to build your project and since you use a framework project with packages.config, I suggest you could use nuget.exe.See this.You can try these:
1) download nuget.exe from this link and then configure its local address to PATH in the environment variable and make sure that you can call nuget from CMD.
2) open vs command prompt, cd the path of the solution and then type this first:
nuget restore
Then you can type your devenv command line and I am sure that this will execute without any errors.
devenv xxxx.sln /rebuild
Besides,you can add a custom target in any xxx.csproj file of your solution like this:
<Target Name="restoresolution" BeforeTargets="BeforeBuild">
<PropertyGroup>
<nugetpath>C:\tools</nugetpath> /////the local path of the nuget.exe
</PropertyGroup>
<ItemGroup>
<slns Include="$(MSBuildProjectDirectory)\..\**\*.sln" />
</ItemGroup>
<Exec command="$(nugetpath)\nuget restore %(slns.Identity)" />
</Target>
Then you can run devenv xxxx.sln /rebuild directly.
I try to build a solution stored in an external GIT-Repository on Visual Studio Online.
It has the following steps:
1: Git Restore - Works
2: NuGet Restore - Works
3: Build - Does NOT work
My first guess when looking at the logs is that MsBuild is not looking for the Packages where NuGet had stored them.
Some Lines from NuGet Restore:
2018-03-14T21:10:11.0352862Z Completed installation of AngleSharp 0.9.9
2018-03-14T21:10:11.0353230Z Adding package 'AngleSharp.0.9.9' to folder 'D:\a\1\s\packages'
2018-03-14T21:10:11.0353563Z Added package 'AngleSharp.0.9.9' to folder 'D:\a\1\s\packages'
2018-03-14T21:10:11.0354972Z Added package 'AngleSharp.0.9.9' to folder 'D:\a\1\s\packages' from source 'https://api.nuget.org/v3/index.json' 'Microsoft.SharePointOnline.CSOM.16.1.7317.1200' to folder 'D:\a\1\s\packages'
Some lines from MsBuild:
018-03-14T21:10:21.2105399Z PrepareForBuild:
2018-03-14T21:10:21.2105793Z Creating directory "bin\Release\".
2018-03-14T21:10:21.2424947Z Creating directory "obj\Release\".
2018-03-14T21:10:30.3569560Z ResolveAssemblyReferences:
2018-03-14T21:10:30.3570425Z Primary reference "AngleSharp, Version=0.9.9.0, Culture=neutral, PublicKeyToken=e83494dcdc6d31ea, processorArchitecture=MSIL".
2018-03-14T21:10:30.3670272Z ##[warning]C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2041,5): Warning MSB3245: Could not resolve this reference. Could not locate the assembly "AngleSharp, Version=0.9.9.0, Culture=neutral, PublicKeyToken=e83494dcdc6d31ea, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
My solution/packages structure is:
....\mysolution\myproject\myproject.csproj
....\mysolution\myproject\packages.config
Current Config:
So how can I change the Nuget and/or msbuild-behavior to make this work?
(Update): To clear this up: I have this problem with every package. They all are in the packages.config, each one is downloaded from Nuget, but each one also isn't found from MsBuild
(Update2) The Commands generated are currently the following:
NUGET:
D:\a\_tool\NuGet\4.4.1\x64\nuget.exe restore D:\a\1\s\AweCsomeO365\packages.config -PackagesDirectory D:\a\1\a\packages -Verbosity Detailed -NonInteractive -ConfigFile D:\a\1\Nuget\tempNuGet_22.config
MSBUILD:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\msbuild.exe" "D:\a\1\s\AweCsomeO365\AweCsomeO365.csproj" /nologo /nr:false /dl:CentralLogger,"D:\a\_tasks\VSBuild_(GUID)\1.126.0\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll";"RootDetailId=(GUID)|SolutionDir=D:\a\1\s\AweCsomeO365"*ForwardingLogger,"D:\a\_tasks\VSBuild_(GUID)\1.126.0\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll" /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation=D:\a\1\a /p:ReferencePath=D:\a\1\a\packages /p:platform="anyCPU" /p:configuration="Release" /p:VisualStudioVersion="15.0" /p:_MSDeployUserAgent="VSTS_(GUID)_build_4_22
I replaced the GUIDs; tempNuGetConfig is something that seems to be generated by VSTS dynamically
Still. even if the log states that nuget stores the packages
Added package 'AngleSharp.0.9.9' to folder 'D:\a\1\a\packages'
MsBuild does not seem to find them there:
For SearchPath "D:\a\1\a\packages".
2018-03-16T13:57:42.4625155Z Considered "D:\a\1\a\packages\AngleSharp.winmd", but it didn't exist.
2018-03-16T13:57:42.4625456Z Considered "D:\a\1\a\packages\AngleSharp.dll", but it didn't exist.
2018-03-16T13:57:42.4625730Z Considered "D:\a\1\a\packages\AngleSharp.exe", but it didn't exist.
VSTS-Configurationvalues:
MsBuild: /p:ReferencePath=$(Build.StagingDirectory)\packages
Nuget-DestiantionDirectory: $(Build.StagingDirectory)\packages
(update3): I have no solution file, but only a csproj-file in that repository
The issue was that inside the project there was a hintpath for the packages directing to a location that was not within the GIT-Repository (and shouldn't):
<Reference Include="AngleSharp, Version=0.9.9.0, Culture=neutral, PublicKeyToken=e83494dcdc6d31ea, processorArchitecture=MSIL">
<HintPath>..\..\AweCsome365Test\packages\AngleSharp.0.9.9\lib\net45\AngleSharp.dll</HintPath>
</Reference>
My original approach was to define a target directory to NuGet and a Source Directory for MSBuild to use another location to the packages that both understand.
The issue though (as far as I understand) is, that NuGet always creates a subfolder-structure "./packages/{PackagesName}/lib/net45/{file}" and MSBuild does not look recursivly when setting "./packages" as source path.
The above is just an explanation for the future guy running into the same problem
So my solution was to mimic the local behavior for nuget and changing the output directory to match the HintPath (even if there is no "AweCsome365Test")-directory in the repository:
(I will leave this question open as this solution smells fishy. If anyone has a better solution that allows to chain nuget and msbuild without using the HintPath I am happily willing to spend my bounty on it)
I believe that your MSBuild "ReferencePath" parameter is not correct. you are telling MS Build that all your references (nuget packages and their dlls included) are going to be located at "D:\a\1\a\packages" but that is not where nuget will download and store the packages and dlls. Nuget will download and extract files into D:\a\1\a\packages\{packageName}\{version}\lib\{environment}\package.dll. I think you need to remove that last parameter (ReferencePath) from your MSBuild arguments.
I also noticed that your PackageLocation parameter is not the same as the destination for the NuGet restore task, do you need to add the "\packages" to that parameter like the destination in the restore task?
Change the nuget restore destination directory to $(Build.SourcesDirectory)\packages and remove the msbuild ReferencePath parameter.
The answers here are largely right. However it's worth noting another cause that can result in this behaviour. My toolchain was using Azure DevOps which is basically the same as Visual Studio Online, just a few years later.
Cause:
Reference your project from a different solution (cross-repo), for instance for debugging purposes
Update NuGet references in the problematic project from the external place you referenced it from
What this does is make use of the solution location for packages when the package gets installed.
For .Net core/standard projects, using Update-Package -reinstall appears to fix things. However, for .Net Framework projects, even though packages.json may get rebuilt, the <HintPath /> node in the .csproj gets left as is - with a reference to a packages folder that Azure will never create.
Simple fix:
Right click on the offending solutions locally, and choose Unload
Right click on the unloaded project, choose edit .csproj
Find any hintpaths that look like ../../OtherRepo/packages (the slash in use may vary), and change them to ../packages
Confirm the solution does build locally still
Push the changes to Azure, and cross your fingers
This approach will fix the issue caused by consolidating / updating packages from the wrong place rather than requiring a change to the build pipeline to spoof that location (which in may case, wasn't working very well either).
perhaps Im getting old but Im really confused on how to use a nupkg on Linux. Resolving and installing dependencies/adding libs for C is easier for me (never would thought I would say so).
I got a package from a vendor (YYYYY_linux.3.0.77.nupkg) and want to run their example code (version for windows with visual studio worked out of the box) but they told me their linux pack would also work.
What I did:
dotnet init
... coding ...
dotnet restore
dotnet build
/home/tobiass/code/XXXX/Program.cs(27,11): error CS0246: The type or
namespace name 'YYYYY' could not be found (are you missing a using
directive or an assembly reference?)
Afterwards I tried two things:
1.
I edited NuGet.Config
dotnet restore
The nupkg shows up as a feed.
But I still get the same error.
2.
I also tried to create a local feed
mono nuget.exe add ../YYYYYYY_linux.3.0.77.nupkg -source ./
but it always results in
The requested feature is not implemented.
What is the correct way on Linux to add a library? Must it be also a part of project.json? Some config in .nuget?
Best,
Tobias
I suspect your project is not a .NET Core project so you should be using nuget.exe instead of dotnet.
So first I would take a look at the example code. Does it have a .csproj file? Does it have a packages.config file? Does it have a packages folder with the .nupkg file in it already? If so then nothing needs to be done and it should just compile.
From the error message one or more of the above are not correct. If the project file (.csproj) has references to the files in the NuGet package and there is an existing packages.config file then all you need to do is restore the package. To do that you need to put the NuGet package somewhere so it can be restored. You could simply just copy the .nupkg file into ~/.local/share/NuGet/Cache/ which is the machine cache for all NuGet packages and then restore it into the project by running nuget restore Path/To/YourSolution.sln.
If the project does not have a packages.config file then you would need to install it into the project. The simplest way would be to use MonoDevelop. That has built-in support for adding NuGet packages to projects.
Otherwise you could just unzip the .nupkg file and copy the files where they need to go into the solution's packages directory based on the information in the .csproj file.
I'm working on a program that uses a Dymo labelwriter 450, using a custom reference to interact with it from my c# program. I'm using DYMO.Label.Framework
When I sync with GitHub and Travis tries to test the software, it can't compile because it's missing a reference. error CS0246: The type or namespace name 'DYMO' could not be found. Are you missing an assembly reference?
I made sure to add the DLL to the project directory and reference it from the project using a relative path.
Is there something I need to add to the travis config? I can't find the package on NuGet.
Thanks.
Travis works fine with references, even nuget packages are actually referenced by relative path. Make sure your dll is pushed to github and saved to the right place. Project directory (not bin or something) should be the basis of relative path. One more thing to note -- path strings are case-sensitive as travis works on mono.
References like this worked for me:
<Reference Include="Nustache.Core">
<HintPath>..\..\Tools\Rosalia\Nustache.Core.dll</HintPath>
</Reference>
In Visual Studio 2012 I have Slow Cheetah version 2.5.10 installed. When building an app that uses Slow Cheetah, the build fails with the following error:
Error 1 The "SlowCheetah.Xdt.TransformXml" task could not be loaded
from the assembly
C:\Users\MyActiveDirectoryAccount\AppData\Local\Microsoft\MSBuild\SlowCheetah\v2.5.10\SlowCheetah.Xdt.dll.
Could not load file or assembly
'file:///C:\Users\MyActiveDirectoryAccount\AppData\Local\Microsoft\MSBuild\SlowCheetah\v2.5.10\SlowCheetah.Xdt.dll'
or one of its dependencies. The system cannot find the file specified.
Confirm that the declaration is correct, that the assembly
and all its dependencies are available, and that the task contains a
public class that implements
Microsoft.Build.Framework.ITask. C:\Users\MyActiveDirectoryAccount\AppData\Local\Microsoft\MSBuild\SlowCheetah\v1\SlowCheetah.Transforms.targets
When navigating to this directory, I can see the Slow Cheetah files, but the SlowCheetah.Xdt.dll file is missing.
C:\Users\MyActiveDirectoryAccount\AppData\Local\Microsoft\MSBuild\SlowCheetah\v2.5.10\
To triage this, I've:
Rebooted
Un-installed and re-installed Slow Cheetah
Clean and rebuild
None of the above fixed the problem. Any guidance would be appreciated. Thanks!
The answer is in one of the Q & A's (by zendu)
Copy the files from
%APPDATA%..\Local\Microsoft\MSBuild\SlowCheetah\v1.
to
%APPDATA%..\Local\Microsoft\MSBuild\SlowCheetah\v2.5.10.
List of files:
Install-Manifest.xml
Microsoft.Web.XmlTransform.dll
SlowCheetah.Tasks.dll
SlowCheetah.Transforms.targets
SlowCheetah.Xdt.dll
Source
Also see this related question
The "SlowCheetah.Xdt.TransformXml" task could not be loaded from the assembly
I had the same problem with Visual Studio 2010. I just install the SlowCheetah nuget package (install-package SlowCheetah) and after that the build succeed. The nuget package set up correctly the slowcheetah task in your solution.
SlowCheetah nuget Package