I'm pushing a NancyFx solution to AppHarbor, but it fails to build since AppHarbor isn't restoring the packages.
Package restore is defined in my solution file though.
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = ".nuget", ".nuget", "{313EB245-8733-45FC-82B3-6C1404446A50}"
ProjectSection(SolutionItems) = preProject
.nuget\NuGet.Config = .nuget\NuGet.Config
.nuget\NuGet.exe = .nuget\NuGet.exe
.nuget\NuGet.targets = .nuget\NuGet.targets
EndProjectSection
EndProject
Here is a relevant piece of the AppHarbor log.
Build started 11/21/2012 8:50:07 AM.
1>Project "D:\temp\cqcytykz.jkt\input\src\xxx\xxx.sln" on node 1 (default targets).
1>ValidateSolutionConfiguration:
Building solution configuration "Release|Mixed Platforms".
1>Project "D:\temp\cqcytykz.jkt\input\src\xxx\xxx.sln" (1) is building "D:\temp\cqcytykz.jkt\input\src\xxx\xxx\xxx.csproj" (2) on node 1 (default targets).
2>PrepareForBuild:
Creating directory "obj\Release\".
ResolveAssemblyReferences:
Primary reference "Nancy".
2>C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1578,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "Nancy". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. [D:\temp\cqcytykz.jkt\input\src\xxx\xxx\xxx.csproj]
Anyone having an idea what's missing?
Is there a section in the csproj that references the NuGet.targets file? What you have just shows the items in the solution, the project needs a reference to the targets file to actually know what to execute upon build of a project.
The NuGet support isn't really anything special that MSBuild/VS knows about it (though VS does have an extension to make some things easier). The stuff (which should be inserted if you use the VS extensions "Enable Package Restore" functionality) is what tells MSBuild it needs to run an external command during build, which is what then restores the packages :-)
Related
Im having build errors after building my Visual Studio Core repository from Team Foundation Server. My build order is Get Sources -> NuGet Restore, Build Solution, Publish Artifact
NuGet restore points to my NuGet.config file.
Looking at the error, it seems to me that my NuGet files are not being compiled. My Nuget files are pointing to a location in my file system. I can compile and run my program on VS but i cant successfully build using TFS.
Example errors:
project.assets.json not found, run a nuget restore to generate this file.
- After looking, I found the file in the same location it said not found?
The type or name space "System" could not be found
- Im getting this error for all 8 NuGet packages????
The NuGet.config can't be pointing to your file system if you expect the restore to work on a machine other than yours. It has to be pointing to a location that the build server can access.
I'd recommend setting up a Package Management feed containing your packages.
When VS2017 was used to create a stateful solution, producing the standard boilerplate code, the resulting two projects have two different MSBuild versions.
The application uses MSBuild version 1.5.0.
The service uses MSBuild version 1.6.0 (the current "latest").
If I run the solution this way, it runs fine on my local Service Fabric cluster.
But when after I use NuGet to update the application's MSBuild to 1.6.0 (so both application and server projects use the same), the following errors occur.
Severity Code Description Project File Line Suppression State
Error The OutputPath property is not set for project 'gt_strd5.sfproj'. Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='Debug' P follow a project-to-project reference to this project, this project has belatform='x64'. This error may also appear if some other project is trying toen unloaded or is not included in the solution, and the referencing project does not build using the same or an equivalent Configuration or Platform. gt_strd5 C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets 737
Severity Code Description Project File Line Suppression State
Error MSB4057 The target "CreateManifestResourceNames" does not exist in the project. gt_strd5 C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets 2630
I found that after the change, some references in the application's project file continued to reference MSBuild 1.5.0. In my case, the gt_strd5.sfproj file contained four references which needed to be updated from 1.5.0 to 1.6.0. See the snippets from the XML below.
Import Project="..\packages\Microsoft.VisualStudio.Azure.Fabric.**MSBuild.1.5.0**\build\Microsoft.VisualStudio.Azure.Fabric.Application.props" Condition="Exists('..\packages\Microsoft.VisualStudio.Azure.Fabric.**MSBuild.1.5.0**\build\Microsoft.VisualStudio.Azure.Fabric.Application.props')"
.....
Import Project="..\packages\Microsoft.VisualStudio.Azure.Fabric.**MSBuild.1.5.0**\build\Microsoft.VisualStudio.Azure.Fabric.Application.targets" Condition="Exists('..\packages\Microsoft.VisualStudio.Azure.Fabric.**MSBuild.1.5.0**\build\Microsoft.VisualStudio.Azure.Fabric.Application.targets')"
To verify this, I went back a couple times and was able to reproduce both the issue and this solution.
Hope it saves someone else some time.
Best Regards
I was getting this error into PCF control.
Run Developer Command Prompt VS2017/ VS2019
a) Remove white space from your folder like Test%20-%20PCFs (source control generated name) should be TestPCFs
b) Go to pcf project folder from cmd line & run msbuild /t:restore
b) Go to cds project folder from cmd line & run msbuild /t:restore
c) On cds project folder, run msbuild
d) For release deployment run msbuild /p:configuration=Release
For other types of projects
a) Remove white space from your folder name
b) run msbuild /t:restore
c) run msbuild
I have 3 projects; Project1.Web, Project1.Service and Project1.Common.
Both Project1.Web and Project1.Service have dependencies on Project1.Common.
If I rebuild the solution which contains all 3 projects; all works correctly.
If I change a file in Project1.Web; files are built to Project1.Web\bin - all works correctly.
If if change a file in Project1.Service files are built to Project1.Service\bin\Debug AND some are copied to Project1.Web\bin. The copied file is Project1.Common.dll, but Project1.Web.dll is not built (or copied).
The file modified in Project1.Service is not shared, its just modified to trigger an incremental build of Project1.Service.
Does anyone know why Visual Studio would be copying a build artifact to a a directory that is not part of the incremental build?
Currently this sequence of events leaves Project1.Web is a non-working state as Project1.Service and Project1.Web have dependencies on different versions of the same assembly via a third party assembly. If we decide to make a change to Project1.Service then it has the side-effect of breaking Project1.Web.
I've tried/checked the following:
There are no dependencies between Project1.Web and Project1.Service (either direction).
The file modified in Project1.Service is not shared; and there are no pre/post build events defined.
Executing msbuild on the Project1.Service.csproj project file does not have the same effect.
Denying write/create permission on the bin directory under Project1.Web does not cause the incremental build to fail.
No output is emitted in the detailed or diagnostic msbuild output that references Project1.Web (from within Visual Studio)
Using procmon, I can see that devenv is using mswebprj.dll (C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Packages\mswebprj.dll) - which invokes the copy of the file.
I have a problem with the standard MSBuild.exe used on our Team Build server, the standard version used is in
"C:\Windows\Microsoft.NET\Framework\v4.0.30319", version 4.0.30319.18408 or
"C:\Windows\Microsoft.NET\Framework64\v4.0.30319" respectively (same version).
Using this version leads to Fake dlls not being generated in the same way as on our local development machines (i.e. some fake methods are missing on the server), resulting in broken builds (unit tests) on the TFS.
I updated the build definition template to use the MSBuild version located under "C:\Program Files (x86)\MSBuild\12.0\Bin" as it is more recent (version 12.0.30723.0), however, this results in an error MSB1025, System.Threading.Tasks.Dataflow, Version=4.5.9.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a not found.
Update
Further investigation - manually adding the System.Threading.Tasks.Dataflow.dll with the correct version number to the MSBuild directory results in a broken build with
Unsupported ToolsVersion 12.0
Manually setting the ToolVersion in the Microsoft.TeamFoundation.Build.Workflow.Acitvities.MSBuild element to "4.0" results in a broken build with
Cannot set unknown member "Microsoft.TeamFoundation.Build.Workflow.Activities.MSBuild.ToolVersion"
So... no real improvement.
Any ideas how to fix this?
Fakes is sensitive to the Visual Studio version. Try passing /p:VisualStudioVersion=12.0 to MSBuild arguments. Also avoid handling System.* assemblies manually.
I'm using Vs2010 and Wix 3.6.0917.0, for the record. I use the $(SolutionDir) property quite a bit in my .wixproj file, since I only ever build the installer as part of a solution build or as part of a team build, and never by itself. However, while building from the command line works just fine (both from cmd on the desktop and when building on build agents), when I attempt to reload the .wixproj file into the IDE, I get errors because all the $(SolutionDir) variables are resolving to the project directory, not the solution directory. Consider:
C:\workspace\projectCollection\teamProject\branch\solution.sln
C:\workspace\projectCollection\teamProject\branch\source\installer\installer.wixproj
and assume a shared custom targets file:
C:\workspace\projectCollection\teamProject\branch\build\shared.targets
which is referenced inside installer.wixproj with:
<Import Project="$(SolutionDir)build\shared.targets">
Command line builds work fine...
C:\workspace\projectCollection\teamProject\branch\> MSBuild /t:build /property:Platform=x64;Configuration=Debug solution.sln
0 Errors
0 Warnings
Build succeeded!
But load into vs2010 and you see...
The imported project
"C:\workspace\projectCollection\teamProject\branch\source\installer\build\shared.targets" was not found.
Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
C:\workspace\projectCollection\teamProject\branch\source\installer\installer.wixproj
You can see here that the resolved result of $(SolutionDir)build\shared.targets is getting the project directory and not the solution directory. What gives?
My guess would be that $(SolutionDir) resolves to nothing when the wixproj is being loaded into VS2010. In this case the imported file becomes "build\shared.targets". Since the path is relative it is assumed to be relative to the project directory. Using ".." or some other path could get you around the problem.
I verified this failed with WiX 3.5.2222.0 in VS2010. A C# console application project (csproj) worked as expected.
Have you filed a bug against WiX for this?
I looked at the WiX vs2010 addin code a little bit and the Solution properties are only created when doing a build and not when the project is loaded.