I have a project which has Entity Framework version 4.6.4 installed. The relevant line from the packages.config folder shows:
<package id="EntityFramework" version="6.4.4" targetFramework="net47" />
If I do a clean and build the project rebuilds with zero issues.
However if I run a devops build pipeline as follows:
The process falls over with an error stating that
The type or namespace name 'Core' does not exist in the namespace 'System.Data.Entity'
To the best of my knowledge all of the build errors seem to be related to Entity Framework and the Nuget Restore step prior to the build step seems to show packages being restored successfully.
Any pointers would be much appreciated.
Related
I updated the Target Framework of all the Projects in my solution from 5.0 to 6.0.
I also had to Upgrade the Target Framework of 2 dependency NuGet packages that I own which are imported from a Releases source in Azure.
After doing this, and adding a step in the Build pipeline to load the correct version of the SDK, I started getting the following error repeated for every project when a step tries to build and run the tests:
F:\BuildAgents\_work\286\s\[Proj Name]\[Proj Name] : error NU1301: Unable to load the service index for source https://pkgs.dev.azure.com/[redacted]/_packaging/Releases/nuget/v3/index.json.
Failed to restore F:\BuildAgents\_work\286\s\[Proj Name]\ [Proj Name] (in 18.5 sec).
Does anyone know what could be causing this? The error code suggests the source is not available but the build step prior successfully adds the source!
The NuGet source:
The updated dependency artifacts which I believe the source uses:
The Pipeline:
The BUILD step BEFORE the error:
This turned out to be some sort of authentication error for the NuGet source.
Why? No idea. The password being stored was correct.
The fix was deleting the password variables in Azure and re-adding them from scratch for each pipeline.
It seems my team mates have turned off their nuget server and gone on holidays.
I need a temporary work around so that my Azure Dev Ops build does not fail when restoring the nuget packages.
I have a local copy of the package at
C:\Users\kirst.nuget\packages\mypackagetemp
Which I want to publish to a temporary feed.
I read the instructions on publishing a package from the command line but am confused about step 6
Surely I dont need to set up the Project and restore packages as I already have the .nupkg
I tried the command
c:\nuget\nuget.exe push -Source "TempFeed" -ApiKey az mypackagetemp.nupkg
but got an error
unable to load the service index for source
https://pkgs.dev.azure.com/mycompany/myproject/_packageing/TempFeed/nuget/v3/index.json
When I repeat the command I get a request for credentials
When I put in the credentials I connect to Azure Dev Ops with they do not work.
[Update]
I was prompted for credentials.. reading up on it... so confusing.
[Update]
I upgraded nuget.exe from 5.1.0.6013 to the latest version 5.4.0.6315 This time I got a UI to log in and the message
Your package was pushed
However when the devops pipeline build runs I het a message
unable to load the service index for source
https://pkgs.dev.azure.com/mycompany/myproject/_packageing/TempFeed/nuget/v3/index.json
I guess I need to create an index.json file somehow.
My project is using a mynuget.config that has the following in the packagesources
<add key="TempPackage" value="https://pkgs.dev.azure.com/mycompany/_packaging/myfeed/nuget" />
[Update]
I changed mynuget.config to have
<add key="TempPackage" value="https://pkgs.dev.azure.com/mycompany/_packaging/myfeed/nuget/v3/index.json" />
Now the dev ops build shows the message
Failed to retrieve information about 'Serilog.Enrichers.Thread'
from remote source
'https://pkgs.dev.azure.com/mycompany/_packaging/myfeed/nuget/FindPackagesById()?id="Serilog.Enrichers.Thread'',
response status code does not indicate success: 404 (Not Found).)
My solution does use Serilog. I don't think the 3rd party package uses it.
[Update]
The next time I built I got a different error looking for WindowsAzure.Storage
I seem to get a different file causing the error each time I build the pipeline.
My project artifacts does have 2 feeds. The needed files are in the unselected feed.
[Update]
I tried editing mynuget.config to use index.json however I get a build error
The nuget command failed with exit code(1) and error(Unable to load
the service index for source
https://pkgs.dev.azure.com/mycompany/_packaging/myfeed/nuget/v3/index.json.
Response status code does not indicate success: 404 (Not Found - The
feed with ID 'MyFeed' doesn't exist
[Update]
Because the new feed was project based I edited mynuget.config to have
<add key="TempPackage" value="https://pkgs.dev.azure.com/mycompany/myproject/_packaging/myfeed/nuget/v3/index.json" />
Now it works!
In Azure Devops web portal, for your current project, go Artifacts tab and make sure your packages like mypackagetemp.nupkg are available there.
For me, I have custom LibraryCore.nupkg pushed there. Now let's click the Connect to feed settings, choose nuget.exe and you can see:
Copy exactly same content to your own mynuget.config file. Then your build pipeline can access your published mypackagetemp.nupkg.
Failed to retrieve information about 'Serilog.Enrichers.Thread' from
remote source
'https://pkgs.dev.azure.com/mycompany/_packaging/myfeed/nuget/FindPackagesById()?id="Serilog.Enrichers.Thread'',
response status code does not indicate success: 404 (Not Found).)
The next time I built I got a different error looking for
WindowsAzure.Storage
These packages(Serilog.Enrichers.Thread,WindowsAzure.Storage and ...) are all available in nuget.org, so you should also make sure you've add nuget.org as package source in your config file:
In addition:
According to your description, you only need to use your custom devops feed and other packages from nuget.org, apart from using your mynuget.config, you could configure your nuget restore task like this:
Choose devops feed directly(second red line) by Feeds I select here instead of Feeds in my Nuget.config. And check the Use packages from nuget.org checkbox. Then you can access the packages in custom feed and nuget.org during build.
I need to create nuget package for a .net core 2.1 as part of build and release process in Azure Devops
What I would like to do
1) In the build section build the project and then add the compiled code to artifact
2) In Release definition will have 2 deployments one for Beta release where the version will be like 1.2.3-Beat.2 and push to azure artifact nuget and another deployment to release where the version will be like 1.2.3.2 and push to azure artifact nuget.
Currently I have only one build definition which will build (nuget package gets created during build process) and push to azure artifact nuget.
Pipeline I would like to create
Use the dotnet pack task with the --no-build option, and in your pre-release stage set the VersionSuffix value.
Note: My current team uses a set of Powershell scripts to append build number data to the Major.Minor data found in the .csproj (or AssemblyInfo.cs for netFramework), but that doesn't change the answer to your question. Once you figure out what the Major.Minor.Patch[.Build] data is going to be, you can use the VersionSuffix property in a dotnet pack task with --no-build to communicate quality of the package as it moves through your pipeline.
Given a .csproj file that looks like this:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
<PropertyGroup>
<PackageVersion>1.0.0.1</PackageVersion>
<AssemblyVersion>1.0.1812.201</AssemblyVersion>
<FileVersion>1.0.1812.201</FileVersion>
</PropertyGroup>
<ItemGroup>
<Content Include="Assemblies\*">
<Pack>true</Pack>
<PackagePath>lib\$(TargetFramework)</PackagePath>
</Content>
</ItemGroup>
</Project>
Again, if we ignore the versioning step that we use, the dotnet pack task in the pipeline image above will produce a package with the version 1.0.0.1-Beta.
Then in your stable release stage, don't set the suffix value and let the package get its version from the .csproj file like normal (eg. 1.0.0.1).
The elements and values in the sample .csproj file above can be written as direct edits to the .csproj or they can be set using the Properties >> Package tab.
If the values are not changed in the properties menu or added explicitly, the elements and values do not appear in the .csproj and are assumed by dotnet build|test|pack commands.
Finding the right combination of these properties and values can be daunting if you aren't familiar with how they're fitted together. I found this article useful when trying to decipher the version properties.
Also, you should understand 1.0.1-b2 < 1.0.1, so your pre-release version might be 1.2.3.2-beta1 and your stable version would be 1.2.3.2.
As the package version is included the moment you perform 'nuget pack', which you would generally perform during build, it might become a bit complicated to change that version afterwards.
What may be interesting in your case is using the concept of views in Azure Artifacts, this would allow you to promote a package to the release view at a later state without having to rebuild the package.
There is a nice extension on the marketplace that would allow you to do this from within a release: https://marketplace.visualstudio.com/items?itemName=rvo.vsts-promotepackage-task
using this flow you can have the packages in the pre-release view/feed as long as you like and make them available in the release view whenever you see fit.
downside of this is that the packages are not identified as pre-release packages by Nuget as you would not be packaging them with the proper semver for that
I am trying to learn how to use Go CD to implement continuous integration into my company's workflow. I'm using GitHub for my source control and have my pipeline set up to monitor the repository for changes and attempt to rebuild whenever there's a change. All that is working fine. Now I'm trying to add unit tests to the pipeline and can't get the unit test project to build.
This is the config xml for my build command:
<exec command="%Windir%\Microsoft.NET\Framework64\v4.0.30319\MsBuild.exe" workingdir="UnitTest">
<arg>/T:rebuild</arg>
<arg>/P:Configuration=Release</arg>
<arg>/m</arg>
<runif status="passed" />
</exec>
This is the relevant part of the error that I'm getting:
The missing file is ..\packages\MSTest.TestAdapter.1.1.18\build\net45\MSTest.TestAdapter.props
The unit test project uses some NuGet packages, so it needs these files to build properly, but they are not in the working directory for GoCD. I added a job to my pipeline before trying to build the unit tests that restores the NuGet packages to the location specified in the error message. Here is the config xml for my restore nugget command:
<exec command="C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\ReadyRoll\Octopack\build\NuGet.exe" workingdir="UnitTest">
<arg>restore</arg>
<arg>packages.config</arg>
<arg>-PackagesDirectory</arg>
<arg>..\packages</arg>
<runif status="passed" />
</exec>
When I re-ran the pipeline and monitored the working directory, I see the NuGet files get created when the "restore" step is run, however building the unit test project deletes the files and I still get the error.
I thought this was because I was using /T:rebuild in my MSBuild command, but it still deleted the files when I changed it to /T:build.
Can anyone give me a tip on how add a job to my pipeline that builds a project using NuGet packages? I thought about adding the "NuGet.exe restore" command to the project file, but I couldn't figure out how to do it (or if it can be done?).
Thanks in advance!
I figured out what I was doing wrong. I set up the build and restore commands in separate jobs, I needed to make them both tasks in the same job. I did that, and it worked.
I think this has something to do with how GoCD checks out the material for each job? But since I'm so new to this (and may not be right about the reasons), I'm not going to speculate about why this changed caused it to work.
If anyone knows the reason, I'd be happy to know.
I've got a build running in VSTS which is restoring NuGet packages from both nuget.org and a custom feed in VSTS. The custom feed is in the solutions NuGet.config as a <packageSource>, along with the user name and password in <packageSourceCredentials>
The build, including the restore, is working Ok, but there is a warning ...
2016-10-12T16:18:57.6589001Z ##[warning]To connect to NuGet feeds
hosted in your Team Services account/TFS project collection with
NuGet 3.1 or below, edit your build definition to specify a path
to a NuGet.config containing the package sources you wish to use.
How can I remove this?
Based on my test, that warning remains even through using higher version of nugget (e.g. 3.3) or do not restore package from VSTS feed. (Hosted build agent has the same result).
You can’t remove it unless you custom a build task to restore package through command line.
I submit a issue here.
Update:
The issue has been updated.
I see the issue in the code coming from our transition from depending
on assets coming with the agent to being deployed with the task. You
can get around this for now until we get an official change out by
either (1) choosing to use the Nuget 3.5 version radio button in the
task config or (2) supplying a path to your nuget.config.
So, you can use Nuget 3.5 version or specify nuget.config file.