I have a .NET Web Application, and I include some 3rd party references in a folder called references. That folder is in the same directory as the Visual Studios solution, but not the same directory as the Project File. Now, when I first create this project, add my references, and build - everything works perfectly. However - once I check in to TFS and then try pulling down the code, the references cannot be found. They still exist in the "references" folder that I created, but they are not showing up in the bin folder. Any suggestions on what I can do to fix this? I'm using Visual Studios 2012.
When you checkin to TFS, make sure you checkin those DLLs. By default, TFS excludes binary files during checkin.
Also, if those 3rd party Dlls are hosted on Nuget, then use Nuget packages to add/manage references. That way, you do not have to bother checkin them into TFS. You can simply enable Nuget's package restore on build (right click on Solution -> Enable Nuget Package Restore). More info here.
Related
I am fairly new to C# development and my organization has a location on one of their servers that contains nuget packages that were created by a past developer. I have the location of the packages mounted on my machine as a network location, when I try and add a new package source and browse to the location of the directory containing all of the .nupkg files and then browse for the packages in the NuGet Package Manager it comes up with no results. I have even downloaded the packages to my local machine and tried adding the source to the directory that is on my C: drive and still I get no packages to pick from. What am I doing wrong?
NuGet has documentation on installing packages and adding sources in Visual Studio.
Although, I'm not a fan of using the Visual Studio options page to add sources. When you add a source there, it's added to your user profile's nuget.config file, which means that all solutions on the same computer will use that source (unless the solution has it's own nuget.config file that uses <clear /> to remove all inherited sources). It also means that if you share the project/solution, anyone else using the solution will not have the correct sources. So, it's best to add an nuget.config file next to the solution and set up the correct sources there. A quick way to get started is to use dotnet new nugetconfig from a command line, assuming you have the .NET Core SDK installed.
I have a C# project on Git that uses libraries from NuGet. Everything works fine, but when I pull on a fresh new machine and open the solution in Visual Studio it won't compile because of broken references. If I click on the references under the project I can see the classic warning sign with the yellow exclamation mark.
Nuget restore won't do anything (and I still haven't found any use of this feature...), files repositories.config are fine. If I right click on solution and then 'Manage NuGet packages for solution' no installed package is shown.
To this day I solved it this way: run
Install-Package package_name
it says:
'package_name' already installed.
My_project already has a reference to 'package_name'.
...and after that it shows the packages on the Manager, already assigned to the correct project.
NOTHING HAS BEEN CHANGED in the code ANYWHERE, I can see that because there are no differences on Git.
I have to do it only once on new machines, but it's really annoying. Any idea?
NuGet version: 2.8.60318.667
UPDATE 27/07
I tried the procedure from scratch on another PC, with windows 10, and everything works... same version of Visual Studio, NuGet, etc... I'm baffled
This is probably because of the incorrect path of the .dll in your .csproj. The package restore downloads the packages to the local directory. It doesn't change the reference path of the assembly in the .csproj, meaning that the project will still try to locate dlls on the local directory. The yellow mark means the project is unable to locate the assembly.
Unload the project, right click on project and select "Edit .csproj", and verify the path of missing dlls. For example - If you have NUnit,
<Reference Include="nunit.framework">
<HintPath>..\packages\NUnit.3.6.1\lib\net45\nunit.framework.dll</HintPath>
</Reference>
verify if the dll is present inside "\packages\NUnit.3.6.1\lib\net45" directory.
From the top of my head I can think of a few reasons the packages are not being downloaded, ideally you would have to share a few more details.
First the install-package command won't work. Your packages are already installed VS is just unable to download them, so it makes sense that you are getting that error.
First and foremost is this a public package hosted in nuget.org like
System.MVC.Web? Because if this is in a new machine, using a private nuget server, you need to
configure that source in Tools > Options > Nuget Package Manager >
Package Sources. (See https://learn.microsoft.com/en-us/nuget/tools/package-manager-ui for more details)
Check if you have added the folders to your git repo but at the same
time set the exclusion for its contents. To check that when you do a
clean checkout see if the folders exist but are empty. If thats the
case just remove the folders, the git ignore should do its job from
now on, and everyone new clone will do the proper check.
If the two above which are the most likely ones to be the reason do
not work. Try and restore the packages from the Package Manager
Console and update your post with the details.
You can open the Package Manager Console and type:
Update-Package -reinstall
or
Update-Package -reinstall -Project YourProjectName
FYI there's comprehensive document from Microsoft - https://learn.microsoft.com/en-us/nuget/consume-packages/package-restore - on the multiple ways of restoring nuget packages
try removing your package from below nuget cache folder so that NUGET is forced to download from source
C:\Users\<< your user name >>\.nuget\packages
I experienced this issue today, and upgrading to the latest version of VS 2017 (15.8.7) didn't help at all.
Check your packages.config file(s) to see if your packages tag looks like this:
<packages xmlns="urn:packages">
If it does, remove the xmlns attribute so it's just:
<packages>
That fixed it for me!
I have solved this problem. Follow this steps
In Visual Studio, click Tools > Extension and Updates.
Navigate to Online, search for "NuGet Package Manager for Visual
Studio" and click Update.
(If there is no button Update, navigate to Updates > Visual
Studio Gallery, find the "NuGet Package Manager for Visual
Studio" and click Update.)
Then restart Visual Studio.
Even after you've installed it at the Solution level, depending on your default you may have to pick which projects you want it to be available in. That was my problem.
I have a solution in Visual Studio 2015 that uses several NuGet packages. When I build in Visual Studio 2015, the packages are restored properly and the build succeeds. However, when I push that same project to Visual Studio Online, even though I have "Restore NuGet Packages" checked, the build fails because MSBuild cannot find the referenced binary.
I have looked at the build log and see that my packages are all being restored. Why, even though the package is restored, is the referenced binary not found during the build?
I found that the problem was not in the NuGet package restore, but in the way that the hint path was written in my .csproj file. To the fix the problem, change the hint path to point to the solution directory using the $(SolutionDir) variable.
For example, the NuGet restore pulled the Microsoft.WindowsAzure.Storage.dll binary, but it could not be found on the build of the project. To fix this, I had to open the .csproj, find the reference to the dll, and change the path from
..\packages\WindowsAzure.Storage.6.1.0\lib\net40\Microsoft.WindowsAzure.Storage.dll
-- to --
$(SolutionDir)\packages\WindowsAzure.Storage.6.1.0\lib\net40\Microsoft.WindowsAzure.Storage.dll
By using the $(SolutionDir) variable, Visual Studio Team Services was able to find my referenced dll and build my project properly.
You might also consider checking if the file packages.config, which surely resides on you local system, also gets checked in and is under version control.
First, you might want to see if it's present at the build server (image below is from VS Team Services but it's the same general idea in on-site environment.
Secondly, verify that the file's under version control. As a test, see if it appears under Pending Changes if you add a package.
I made a project with a working build start to fail when I added nUnit. Then, as I checked in the package.config file, it started to restore the packages on the server. When I removed the file from the server, the builds starter to fail again. Details are described in this post.
I'm facing a problem where I need to build only one web project from a solution with two web projects in Visual Studio Online.
I have not found how to build only one project using a "Visual Studio Build" step.
It would be great if exist such a way to do this with "Visual Studio Build" step.
I also tried to use an "MSBuild" step. Unfortunately I got a problem when restoring the packages with Nuget. I got the error: ##[error]No file format header found, ##[error]Unexpected exit code 1 returned from tool NuGet.exe. Right after run: Nuget.exe restore Myproj.csproj.
Summarizing:
How can I build only one web project from a solution with multiple web projects in visual studio online build definition?
Update
Here is an image of the error when I'm building. Also i'm getting this using "Visual Studio Build" step or "MSBuild" step.
Also
I found a comment from chrisrpatterson in a VSO issue:
https://github.com/Microsoft/vso-agent-tasks/issues/571
Which he says: You can't run nuget restore against anything other than an SLN file. You should uncheck restore nuget packages on that vsbuild task.
But I need the packages, and I don't want to push my packages folder into my repo.
So, how can I restore the packages and run only one web project from my solution in "Visual Studio Build" step?
Instead of choosing the .sln file, you need to select the .proj file.
Firstly, click the ellipsis button next to the Solution field.
Then choose the .proj file you want to build. For example, the screenshot below shows that the build definition is configured to build the ClassLibrary1 project, instead of the whole solution (contains ClassLibrary1 and ClassLibrary4 project)
You can add a new "Azure App Service Deploy" task to your build definition and set the "Package or folder field" to "$(build.artifactstagingdirectory)**\YOURPROJECT.zip"
You may want to create a solution with just the web project that you want to build.
In visual studio you can create a new project, and in that dialog select "other project types\solution".
The new solution can sit right next to the existing one..
Visual Studio is creating a \bin folder and copying various assemblies into it when I open a web application solution, even before I compile
What is triggering this action?
And how do I control it?
Reason I'm questioning the process, is the assemblies are not the expected ones
This is where Visual Studio puts all the dlls for runtime for your project. Library dependencies that the project needs. All the dlls that Visual Studio needs for a web project are kept here as well as other packages from Nuget that you might add, and your own. If you look in the References section in the Web Project, you will see many of the dlls that appear in the bin directory.
If there are some assemblies there that you do not want. You can try removing the reference from the Reference folder. Right click on the library in the Reference folder and select remove.
Be careful with removing references though, because your project may need it to function.