I have an ASP.NET MVC 4 app developed in VS 2012. The app consists of a main project (MyProject), a unit-test project (MyProject.Tests), an Azure deployment project (MyProject.Azure), and a couple of general-purpose library projects.
When I right-click on either the solution or the main project and select Manage NuGet Packages, I see a bunch of Microsoft updates that have apparently become available in the last month or so. If I click on the Update All button then the updates are apparently installed without any obvious problems, but when I build the solution I get this error message TWICE:
warning : All projects referencing MyProject.csproj must install nuget package Microsoft.Bcl.Build
Ok, so I have two projects that reference MyProject: MyProject.Tests and MyProject.Azure. I can right-click MyProject.Tests, select ManageNuGet Packages, and add Microsoft.Bcl.Build. That gets rid of one of the two warnings. But VS does not give me an option to manage NuGet packages for the MyProject.Azure project.
How do I add the Microsoft.Bcl.Build package to the Azure deployment project?
EDIT:
Thanks to user swell, I now know that a Microsoft Connect issue for this problem has been opened here.
The answer provided by TheESJ is correct, however the wording wasn't clear to me. Since I cannot comment on the answer, I will provide more details here. Specifically, I was having this problem with an Azure project and the following workaround was required to make the warning go away:
When you double-click the warning in VisualStudio, you will be taken to the BclBuildValidateNugetPackageReferences target in the Microsoft.BclBuild.targets file. Above the actual target element, you should find a large comment block that talks about disabling the project reference checks. Since Azure projects cannot have any library references, it is impossible for those Azure projects to fulfill the requirements of this particular build target.
The solution? Disable reference checking from the Azure project since it is impossible to actually add a nuget package reference.
EXAMPLE
So, assume we have two projects: MyAzureProject.ccproj which references MyProject.csproj. Follow these steps:
Right-click on "MyAzureProject" in the Solution Explorer and select "Edit Project File."
Find the project reference to "MyProject." It should look something like:
<ProjectReference Include="..\MyProject\MyProject.csproj">
<Name>MyProject</Name>
<Project>{1d99490e-d140-4897-9890-238e673a5864}</Project>
...
</ProjectReference>
Add the following element inside of the ProjectReference element:
<Properties>SkipValidatePackageReferences=true</Properties>
Your project reference should now look like this:
<ProjectReference Include="..\MyProject\MyProject.csproj">
<Name>MyProject</Name>
<Project>{1d99490e-d140-4897-9890-238e673a5864}</Project>
...
<Properties>SkipValidatePackageReferences=true</Properties>
</ProjectReference>
Right-click on "MyAzureProject" in Solution Explorer and choose "Reload Project."
You should now be able to rebuild and the error should be gone.
If you double click the warning it gives you instructions for disabling the warning.
It is safe to disable for projectreferences from projects that don't yet support Nuget.
See below portion in bold copied from Microsoft.Bcl.Build.targets.
BclBuildValidateNugetPackageReferences
This target can be disabled for a project reference by setting SkipValidatePackageReferences=true for the reference:
<ProjectReference Include="..\pcl\pcl.csproj">
<Project>{664a9e98-fac7-4567-a046-0dde95fddb48}</Project>
<Name>pcl</Name>
<Properties>SkipValidatePackageReferences=true</Properties>
</ProjectReference>
I faced the same issue and was trying to update Microsoft.Bcl.Build.targets; which did not help.
After some investigation found that .csproj file of the Azure Service project must be modified to include <Properties>SkipValidatePackageReferences=true</Properties>.
This was not apparent from the answer of #TheESJ and so decided to post separate answer. Thanks to #TheESJ.
I encountered this issue a number of times, and the Properties method does indeed work, but when dealing with a Wix project, I had to do the following instead:
<AdditionalProperties>SkipValidatePackageReferences=true</AdditionalProperties>
When I used the Properties Xml node, I got a new error:
The OutputPath property is not set for project
'MyInstallerProject.csproj'. Please check to make sure that you
have specified a valid combination of Configuration and Platform for
this project. Configuration='Debug' Platform='x86'. This error may
also appear if some other project is trying to follow a
project-to-project reference to this project, this project has been
unloaded or is not included in the solution, and the referencing
project does not build using the same or an equivalent Configuration
or Platform.
After failing to resolve the issues with any of the above answers, I simply followed the instructions contained within the Microsoft.Bcl.Build.targets file (displayed after double clicking on the error in the build output window).
I unloaded my project (referencing Azure packages), encountering the error. Edited the project file and inserted the following...
<PropertyGroup>
<SkipValidatePackageReferences>true</SkipValidatePackageReferences>
</PropertyGroup>
...at the top of the project file before the first PropertyGroup.
Related
I have a proof-of-concept solution that has a .NET Standard project in it. I use Paket to manage my nuget dependencies. I am able to use paket add and dotnet restore, per these instructions, to add a nuget dependency to that project. When I reopen my solution, I see that a paket.references file has been added to that project, and that a "NuGet" section has been added under the project's "Dependencies" section in "Solution Explorer".
I'm curious, how does VS2017 know what dependencies to list that "NuGet" section?
From the instructions I linked to above:
In contrast to traditional .NET projects Paket will not add assembly
references to your project files. Instead it will only generate a
single line:
<Import Project="..\..\.paket\Paket.Restore.targets" />
This hook tells the .NET SDK to restore packages via Paket's restore
mechanism. A nice benefit is that your project files are now much
cleaner and don't contain many assembly references.
I'm sure I'm missing something, but I don't see anything in Paket.Restore.targets that would tell Visual Studio where to look to find the dependency chain of the nuget package I added to the project. There are no direct references to any dependencies mentioned in the project file.
For context, I have a repo where I'm trying to add a .NET Standard project to a solution that is full of .NET Framework projects. I'm running into an issue where paket add seems to correctly create a paket.references file for the new project, but dotnet restore doesn't seem to be causing the project references to update, resulting in my project not having a reference to the nuget dependency I'm trying to have it reference. I'm having trouble creating a reproducible example (my proof-of-concept seems to be working fine), so I'm trying to better understand how this infrastructure works to help with debugging.
It seems that since VS2010 and MSBuild 4.0, VisualStudio and MSBuild are able to resolve and build project references that are not located within the solution.
Let us create an example to be more concrete. Create a solution called Solution1 with a C# project named A and another project called B. In project B, add a reference to project A. Now create a new solution called Solution2 and click "Add Existing project" and select Project B. There is a warning that can be seen in Solution Explorer and the Warning List.
The trick is that even with "warning as error" we are able to build Solution2.sln. Actually, project A is found
and built by Visual Studio or MSBuild. Let us verify this by opening a VS2010/VS2012 command line and execute the following commands:
msbuild <dirPathToSolution1> Solution1.sln /t:clean **cleaning up solution1 with project A"
msbuild <dirPathToSolution1> Solution2.sln /t:build
ProjectA is effectively built and worse: the warning mentioned above is not even raised there. With previous versions of Visual Studio such situation could not happen (I have tested it with msbuild 3.5 and VS2008).
However, in our situation we would like to prevent such things. Indeed, we have a large source repository with several solutions and many committers. We are reorganizing our dependencies aiming finally to the extraction of smaller repositories. Meanwhile, we do not want developers to add hidden project dependencies without seeing it. We would like to allow only project references "inside" a solution, leaving other dependencies to assembly references.
So the question is "Is there a way, to prevent such solution such as Solution2 to build ?". Ideally, it should not compile with both VS2012 and MSBuild. However a solution involving only the MSBuild command line would do thanks to our Continous Integration.
edit I checked Microsoft.Common.Targets and there does not seem any way to achieve what you want. Either project references are built, or they are not (this is for instance influenced by the BuildProjectReferences flag of my original answer). There is no way to build them selectively depending on which solution they are in unless I'm missing something - which is mainly because project references are set on the project level, not on the solution level: in your project file there is an MsBuild ItemGroup named ProjectReferences and that is used. (Actually this makes some sense: if you ask MsBuild to build projectB.csproj, and B says it references A, then no solution comes into play and you could expect it to build A, after all you are referencing it).
Now as I understand it, you want to prohibit referencing across directories whose structure happens to be represented by solutions. If that is the case, and you really need this, you could probably get away with a tool that parses the MsBuild log and looks for lines like
Project "somedir\projectB.csproj" (2) is building "someOtherDir\projectA.csproj" (3) ...
then extract the directory info from it and make the tool raise an error when they do not match. Then incorporate the tool in your CI server and feed it with the msbuild log files.
original answer
Try with /p:BuildProjectReferences=false on the command line. As the name suggests it will disable building of referenced projects. When building solution1, this should not be a problem since projectA will be built anyway as it is in the solution. However when building solution2, it won't build projectA and you'll get a build error.
First off, let me start by saying that Nuget is awesome. I love it. That being said, there is one thing about it that I have just discovered which is really getting very annoying.
We have an in-house framework which we use for almost all of our projects. So, I recently created a Visual Studio project template for it, along with the VSIX.. had a few problems along the way due to Nuget.. it wouldn't create the new project from a template when the template was referencing the framework.. because the framework was using Nuget and it couldn't find the nuget folders in the new project created from the template. So, solution was to remove nuget from the framework project and only use Nuget for the other projects (anything but the framework). Okay, great.. that solves the problem!
However, now with every Nuget managed project that I open, it automatically adds these 2 lines back into the .csproj of the framework:
<RestorePackages>true</RestorePackages>
and
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />
This is frustrating because we now need to either stop using Nuget altogether OR to keep removing these lines from our framework's .csproj file every time we want to rebuild the template.
Is there any way I can tell Nuget to ignore one project in the solution? In my case, to ignore the framework project...
With a suggestion from Nailuj and also from what I found here: http://samritchie.net/2012/09/17/nuget-packages-in-vs2012-templates/, I tried something that I thought would work, but it didn't serve my needs; that method is just for including the packages in with the new project, which for me is not helpful and doesn't solve the problem (error about missing .nuget targets folders). So, I played with it a bit and came up with something that is not ideal, but is acceptable:
Remove anything and everything to do with Nuget from the project which is to serve as a template. This then causes a problem with the referenced framework, because the framework project is expecting to be managed by Nuget and from this solution it's not, so error occurs... so:
Remove the framework project from the solution and only reference the DLL so it will build, but not complain about missing nuget folders
Rebuild
Export to template
Build VSIX using exported template
Install template
Create a new project from the newly installed template
Enable Nuget package restore on solution of new project
Open Package Manager Console
Notice message about missing packages and agree to download and install them (about 1 minute)
Remove framework DLL reference and replace with actual project (Right-click, Add Existing Project)
Rebuild and run
Celebrate!
I hope this helps anyone else who may find themselves in this predicament. If anyone has a better idea, please let me know. The bounty is still open for another 6 days, so I won't mark this as answer yet.
How to configure TeamCity to build a solution with 2 projects?
I have configured TeamCity to build my solution which has 1 project which is chosen as Startup Project and it builds fine.
I configured it by adding a new Build Step with Runner Type of "Visual Studio (sln)" from its WebUI.
I added a new class library project and added a reference to it from the first project and it builds fine locally.
The .csproj file of the first project now contains this:
<ItemGroup>
<ProjectReference Include="..\ClassLibrary1\ClassLibrary1.csproj">
<Project>{00E69E26-2576-4B9A-9180-CB1877B1D951}</Project>
<Name>ClassLibrary1</Name>
</ProjectReference>
</ItemGroup>
I checked in the code and teamcity fails to build!
error CS0246: The type or namespace name 'ClassLibrary1' could not be found (are you missing a using directive or an assembly reference?)
TeamCity seems to only build the startup project not the ClassLibrary1 although it's referenced.
How could I configure it to build my solution?
Would this be possible using the WebUI or I should be writing e.g. MSBuild scripts?
Thanks,
Team City handles .sln files, so you should not have any problems with mutliple projects.
Make Team City build the .sln files, not a csproj.
If it's already ok, check your reference to see if it points to the project within the solution or if it refers to the assembly file (might cause problem if you change your build configuration for example)
Your reference should look like this
<ProjectReference Include="..\ClassLibrary1\ClassLibrary1.csproj">
<Project>{some guid identifying your project}</Project>
<Name>ClassLibrary1</Name>
</ProjectReference>
To have this result, the reference should be made by right clicking a project on solution explorer, choose add reference and go to the Project section
Actually, the problem was TeamCity was caching because and the solution was to check the below check box from the Version Control Settings:
Agent checkout: Enforce overwrite all files
The reason it was caching was that I'm using the Checkout mode of "Automatically on server" which means it will cache: http://confluence.jetbrains.net/display/TCD65/VCS+Checkout+Mode
I am currently working on a server control for other applications in our company to interface with a WCF service. Every time I make a change code change and recompile the control, I increment the the AssemblyVerison and AssemblyFileVersion class in the AsseemblyInfo.cs by one. For example, my latest build went from 1.0.07.0 to 1.0.08.0.
When the consuming application updates the file by copying the latest file in the bin directory and tries to compile, they receive the following error:
The type or namespace name 'MyControl'
does not exist in the namespace
'MyNamespace' (are you missing an
assembly reference?)
In order to resolve this error, they have to delete the current reference and re-add the reference.
Is there any way to update the server control without having to delete and re-add the reference?
I am not strong naming the server control.
#JPunyon - Do you mean have the consuming application add the server control project to their solution?
In my case it was a project defined using Target Framework: ".NET Framework 4.0 Client Profile " that tried to reference dll projects defined using Target Framework: ".NET Framework 4.0".
Once I changed the project settings to use Target Framework: ".NET Framework 4.0" everything was built nicely.
Right Click the project->Properties->Application->Target Framework
Right-click the assembly reference in the solution explorer, properties, disable the "Specific Version" option.
If none of the solutions above worked, try this 10-second fix.
Navigate to the startup project in solution explorer. Right click, properties > Application > Target framework. Change the target framework to anything else. Press Yes for the confirmation dialog. Give the changes a few seconds to take effect, then switch the framework back to what it was before.
The error will hopefully go away for you like it did for me!
Are you strong-naming your assemblies? In that case it is not a good idea to auto-increment your build number because with every new build number you will also have to update all your references.
I bumped the answer that pointed me in the right direction, but...
For those who are using Visual C++:
If you need to turn off auto-increment of the version, you can change this value in the "AssemblyInfo.cpp" file (all CLR projects have one). Give it a real version number without the asterisk and it will work the way you want it to.
Just don't forget to implement your own version-control on your assembly!
If the code is working previously and is throwing errors now, as mentioned in the above answers one of the config could have been modified. In brute force approach, close the VS editor and delete .vs folder in the same directory of the .sln file. All the config will be cleared and picked up from the repo files.
In my case, I had to change the Copy Local setting to true (right-click assembly in solution explorer, select properties, locate and change value of Copy Local property). Once this setting was changed, publication of my WCF service copied the file to the server and the error went away.
I encountered this error with an Azure DevOps Services (MS-hosted) build pipeline on a TFVC repo.
In my case, I was working within a branch and had accidentally added the reference from the package folder in trunk instead of from the branch. Once I added the reference from within the branch, it started compiling successfully.
I.e., while working on \branch-beta\sierra.csproj, I accidentally referenced \trunk\packages\delta.dll. Obviously, I needed to reference \branch-beta\packages\delta.dll instead. The mixup occurred because the path is not prominently displayed in the Add Reference window and I didn’t check carefully enough.
I found this issue in Visual Studio 2019 Version 16.4.4
I resolved most issues by discovering that the
packages.config
was missing the appropriate reference
eg:
<package id="System.Runtime" version="4.3.0" targetFramework="net461" />
Delete 'Web.Debug.config' and 'Web.Release.config' file for your solution directory,it should remove all errors
While creating new Blank UWP project in Visual Studio 2017 Community, this error came up:
After restoring the NuGet cache the reference resurfaced in the Project.