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.
Related
I'm using a TeamCity build server to try and build an Outlook Addin, I can build & test the code using TeamCity, but when it comes to publishing the app to a folder I get the following error.
Obviously the build server is missing some SDK components to complete the package\publish step.
Does anyone know which Windows SDK I need to get installed on the build server?
Nothing to do. None of the projects specified contain packages to restore.
XXXXXXXX.Outlook.csproj(331,3): error MSB4019:
The imported project "C:\Program Files\dotnet\sdk\7.0.102\Microsoft\VisualStudio\v17.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets" was not found.
Confirm that the expression in the Import declaration "C:\Program Files\dotnet\sdk\7.0.102\Microsoft\VisualStudio\v17.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets" is correct, and that the file exists on disk.
Build FAILED.
I have a strange behavior with msbuild on my Azure Pipeline.
I'm using Azure Pipeline with Self-hosted Windows agents.
Configuration:
My Visual Studio .sln contains two C# projects:
WebService (Rest API)
Business layer
In addition, the Business layer has dependencies on 2 others projects.
Kernel.DataModel
Kernel.DataAccess
The Kernel.DataAcess layer is using the NuGet package "Microsoft.SqlServer.Types" (14.0.314.76)
The Reference "Microsoft.SqlServer.Types" in the project Kernel.DataAccess has "Copy Local = True". Therefore the DLL file should be copied in the output (release) directory.
The problem:
When I run the Azure Build pipeline, the file "Microsoft.SqlServer.Types.dll" is not copied in the "_PublishedWebsites" directory.
To convince myself, I decided to run the same Pipeline on another build machine by changing the Agent Pool. At my surprise the DLL was present in the "_PublishedWebsites" on the second build machine.
Furthermore, I decided to manually run the msbuild command on my local computer and the the DLL was also present in the "_PublishedWebsites...\bin" on my local machine.
Log files:
I also looked at log files on the Build machines and on my local computer.
First build machine -> The DLL file is simply not copied !
Second build machine -> The DLL file is copied from this location.
Copying file from "C:\Program Files (x86)\Microsoft SQL Server\140\SDK\Assemblies\Microsoft.SqlServer.Types.dll" to "F:\AgentLatestBuild\A1\_work\28\b\_PublishedWebsites\ApiProject\bin\Microsoft.SqlServer.Types.dll".
Local machine ->
_CopyFilesMarkedCopyLocal:
Copying file from "C:\TFS\Repos\Src\Project\**packages**\Microsoft.SqlServer.Types.14.0.314.76\lib\net40\Microsoft.SqlServer.Types.dll" to "E:\tfs\build\Microsoft.SqlServer.Types.dll".
Copying file from "E:\tfs\build\Microsoft.SqlServer.Types.dll" to "E:\tfs\build\_PublishedWebsites\ApiProject\bin\Microsoft.SqlServer.Types.dll".
As you can see:
On the second build machine, msbuild is not using the NuGet packages folder but it's using "C:\Program Files (x86)\Microsoft SQL Server\140\SDK\Assemblies\Microsoft.SqlServer.Types.dll"
On my local machine, the DLL is copied from the NuGet packages folder.
Here are my questions:
How msbuild.exe is selecting the source/location of the DLL ?
Is there a way to force msbuild to first use the NuGet packages instead of any others folders ?
I think msbuild should first look in the NuGet packages folder and if the DLL is not found, then it should try to find it from somewhere else. (C:\Program Files (x86), GAC, etc..)
Finally, do you have any idea why the "Microsoft.SqlServer.Types.dll" is not copied at all on the first build machine. The DLL is present in at least three locations. (ie: NuGet packages folder, C:\Program files\ and it is also in the GAC).
It looks like msbuild is lost in the dependency tracking and can't find the file or it won't copy it for some other reasons.
Thanks for your help.
Is it possible that your *.csproj is targetting the wrong HintPath?
Could you check if you have something like this:
<Reference Include="Microsoft.SqlServer.Types">
<HintPath>..\packages\Microsoft.SqlServer.Types.YOURVERSION\lib\net40\Microsoft.SqlServer.Types.dll</HintPath>
</Reference>
thanks
How do I disable "transitive package management"?
I wish to do so, so that I can install a package that I "packed" locally and have in a .nupkg file. When I attempt to do so, I get a messaging stating that The 'Source' parameter is not respected for the transitive package management based project(s) {csproj file}. The enabled sources in your NuGet configuration will be used.
Complete Context
When developing a NuGet package that's not ready for distribution via our NuGet feed, I often create a local .nupkg file like this from the package manager console:
nuget pack {path-to-csproj-file}
This generates a {project-name}.nupkg file, which I can then install in another project by opening it in Visual Studio, navigating to the package manager console, and entering the command
Install-Package {path-to-nupkg-file}
This has worked great and once the NuGet package is ready for distribution, we push it up to Azure DevOps and let the build pipeline there push it into our feed.
However, I just recently inherited a project where the prior developer apparently setup "transitive package management" that prevents this workflow. Here's what I get when I try to install directly from a .nupkg file:
Install-Package C:\Users\Josh\source\repos\SpeakerDiscountManager\SpeakerDiscountData.1.0.5.nupkg
The 'Source' parameter is not respected for the transitive package management based project(s) MembershipApplicationWidget\MembershipApplicationWidget.csproj. The enabled sources in your NuGet configuration will be used.
<snipped several lines of unsuccessfully searching configured package sources>
Install-Package : NU1102: Unable to find package SpeakerDiscountData with version (>= 1.0.5)
Obviously, it doesn't find the package I've specified via file, because it is searching online feeds and it doesn't exist in any of our online package sources--the package is in a testing state, not ready for anyone to use but me.
Based on the error message, I need to turn off "transitive package management" so that I can specify a file source for the package, but I've been unable to turn up any information online about how this is configured.
I did try installing this exact same .nupkg file in another project, using the same Install-Package {path-to-nupkg-file} procedure. This works.
How to disable “transitive package management” for a Visual Studio
project
I think this problem transitive package management is related to your current project structure which has some intricate dependencies, custom rules and so on. Therefore, turning off transitive package management is unpractical. If you create other projects and then install this package by your way, I think it probably will not occur.
As a best workaround, as you said(hint from the message The enabled sources in your NuGet configuration will be used.), add the the local nuget package's path into Nuget Package Source.
In your side, I think you specify -Source xxxxx(the path of the nuget package) to install this package in the package manager console, if so, this function actually is inconvenient.
You can just add the folder path which SpeakerDiscountData.1.0.5.nupkg exists into global nuget package source. Once you have done it, it will applies to any projects in this machine.
It has two ways:
1) VS IDE UI
Tools-->Options-->NuGet Package Manager-->Packages Sources-->add a new key and input the path of the nuget folder. Also, check its option.
2) global NuGet.Config file
(C:\Users\xxxx\AppData\Roaming\NuGet\Nuget.Config and step 1 is just add the path into this file by VS UI Control)
add these:
<packageSources>
<add key="Local Packages Source" value="C:\Users\Josh\source\repos\SpeakerDiscountManager\" />
..........
</packageSources>
After that, you can use your command to install this nuget package.
Note: If the root directory of your solution also has a file named nuget.config, the parameters in it will override the global file. It has the highest priority.
Just go to Vs IDE Tools/Nuget Package Manager/Package Manager Setting And Check The address of Package Sources.
it's something like "C:\Program Files (x86)\Microsoft SDKs\NuGetPackages".
Then Copy your package file into that folder and at last run this command in Package Manager Console:
install-package packagename
I'm using Visual Studio Team Services to build a .NET solution. I have a Nuget Installer task to restore the packages of the solution that is configured as follows:
Nuget.config file has 2 package sources - one is nuget.org (v2) and the other is a custom feed (Nuget Server v2.5.40416.9020). All packages from the nuget.org feed are restored but the ones from the custom feed are not, for each package from the custom feed there is an error message like this:
Unable to find version 'abc' of package 'xyz'
Error:
[error]Error:
C:\a_tasks\NuGetInstaller_333b11bd-d341-40d9-afcf-b32d5ce6f23b\0.2.22\node_modules\nuget-task-common\NuGet\3.3.0\NuGet.exe
failed with return code: 1 [error]Packages failed to install
This was working fine 1 or 2 days ago.
Locally everything seems to work fine. Also, I tried with the nuget version 3.5.0 and a custom version of nuget.exe, without success.
Any suggestions?
I just had this error today. I fixed this error by reviewing the changes in my solution file with our base code branch and found some old lines that weren't supposed to be there. I think they were a result of a bad merge and should have been removed during a conflict resolve.
To fix the issue I simply removed the references that were old and everything built just fine.
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Services", "Services", "{EAECFF2D-7339-4180-8E1E-6DF9EC9EB131}"
EndProject
{3C14F190-6B6A-4913-9681-AFD9B62850FA} = {EAECFF2D-7339-4180-8E1E-6DF9EC9EB131}
{687ECE00-A567-40F3-BFF9-C3B639328F27} = {EAECFF2D-7339-4180-8E1E-6DF9EC9EB131}
Thanks,
Fissh
I have a brand new Visual Studio 2015 project stored in a TFS Git repo. I've configured a build using the standard Default Git build template. The new project builds locally just fine, but fails during the TFS Build with the following error:
This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is ..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.0\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props.
When TFS first creates your Git repository, it includes a default .gitIgnore file which "hides" certain files from your your (Pending) Changes window. One of the wildcard based exclusions in the default .gitIgnore file specifically excludes any files from being checked in under any folder that includes "build/" which includes this specific file. For now, I've commented out that exclusion in the file, and now it shows up in my (pending) Changes window.