I have a VSIX that is built in VSTS. I have a release that I want to publish that VSIX to MyGet. I can upload NuGet packages to my MyGet-NuGet feed, but I can't figure out how to upload VSIX packages to my MyGet-VSIX feed.
This link: Publish to MyGet from a VSTS Build is only for NuGet.
You can do a HTTP POST from your build server to the feed to add a Visual Studio extension from your continuous integration process. The POST URL is in the form of /F//vsix/upload. Note you will have to add the X-NuGet-ApiKeyheader with a valid API key as well.
Another option is adding your VSTS build as a package source to your feed. MyGet will then find the published VSIX and automatically add it to your feed.
This might be a year too late, but I just hit this, and here's how I solved it. I'm doing this against the enterprise version of MyGet, which means I have my own domain name, but other than that things should be the same.
At the end of my build, I added a Command Line Task.
In the script section of the task, I added the following:
curl -X POST --verbose --data-binary #"$(build.artifactstagingdirectory)\templates\Enterprise-Template\EnterpriseBotVSIX\bin\$(BuildConfiguration)\EnterpriseBotTemplate.vsix" -H "X-NuGet-ApiKey: [KEY GOES HERE]" https://botbuilder.myget.org/F/aitemplates/vsix/upload
Related
For debugging I need to push my NuGet packages including Symboles to our self-hosted Azure Devops Server.
Therefore I use the dotnet pack task with the flags --include-symbols and --include-source in my build pipeline. As output I get two files package.1.0.0.nupkg and package.1.0.0.symbols.nupkg.
When I try to push the package.1.0.0.symbols.nupkg package in my release pipeline, I get the feedback:
409 (Conflict - The feed already contains "package.1.0.0".
(DevOps activity ID: 766B8BC7-9AE6-4998-A246-47397236122F)).
I found Publish *.snupkg symbol package to private feed in VSTS on stack. The feedback is that the Azure DevOps Server do not support NuGet Symbols and they suggest to use a symbol server.
Is it a possible workaround to simply rename the package.1.0.0.symbols.nupkg to package.1.0.0.nupkg and push this package to the feed? Is Visual Studio with able to open the debugger inside the sources of these kind of package?
Is there another way to provide NuGet Symbols for debugging on a Azure DevOps Server?
There are multiple questions in your post, let us try to solve them one by one.
Is it a possible workaround to simply rename the
package.1.0.0.symbols.nupkg to package.1.0.0.nupkg and push this
package to the feed?
The answer is no. The error 409 (Conflict - The feed already contains "package.1.0.0" means that you already have one package package.1.0.0.nupkg or package.1.0.0.symbols.nupkg with version 1.0.0 in your feed. So you could not push another package with same version in that feed. Package version in the feed is unique. In order to protect the package from stepping on each other because of the same version of the package.
So, to resolve that error, you need to update the package version, like 1.0.1 (Deleting the old version of the package from the feed will not solve this error).
Is Visual Studio with able to open the debugger inside the sources of
these kind of package?
The short answer is yes. The details will be explained in the next question.
Is there another way to provide NuGet Symbols for debugging on a Azure
DevOps Server?
The answer is yes, we need to configure Visual Studio to enable debugging remote packages. You could refer below Official document and detailed blog:
Debug with symbols in Visual Studio
ASP.NET Core Debugging Nuget Packages with AzureDevOps | VSTS Symbol Server
But when I use nuget install package then only the package.dll is part
of the content which get downloaded from the Azure DevOps Artifacts.
Why is that?
This is expected behavior for installing the package. Because most of the time when we install and use the nuget package, we do not need the debug package, so the installation package will only add the dll we need to the project and will not configure the Symbols package. If we want to debug the package, we have to configure the Symbols package like above links.
The feedback is that the Azure DevOps Server do not support NuGet
Symbols and they suggest to use a symbol server.
The feedback you mentioned in the question is for *.snupkg symbol package not the symbols package. Azure DevOps Server should support publish NuGet Symbols packages, not debug packages, we have to manually configure Visual studio to use the Azure DevOps Server.
BTW, since there are many questions in your post and they are more general, my answer is not very specific. If you have any questions about any specific questions, you are welcome to open a new post with detailed questions.
I want to upload a nuget package to my Github repo's "Packages". This is to say I want to upload a nuget to Github Packages.
However uploading the package with the "dotnet nuget" command automatically sets the description of the package in Github to the description of the csproj file. The problem is that there is no other information about the package, specifically - release notes. That is why, considering my repo already shares the same description, I find the only way to inform users of what was changed in a given version is to write it in the "description" of the package on Github.
Is there a way to specify the description either when uploading the package or after that through use of Github Actions or a CLI or an API or whatever? Because I want it to be done automatically, rather than by hand for every version.
The documentation is silent on this matter.
I want to set up continuous integration and deployment for an XAP Mobile app in Azure Devops.
In order to get CI/CD I need to set up the Azure Pipeline to install the right packages.
There is some information in the docs on Hosting your own NuGet feeds
and Get started with NuGet packages in Azure DevOps
Dev Express explained that they do not currently provide a Nuget feed for XAF, but I can make my own Delegate's DCNugetPackageBuilder
Using DXNugetPackageBuilder to make Nuget packages
As per the instructions I downloaded the .pdb files extracted them to c:\tmp\symbols
I also downloaded DXNugetPackageBuilder and edited buildPackages.bat according to instructions.
Next I ran build.ps1 in elevated Powershell
This created the .nupkg files at C:\tmp\Nuget
By default this uses the files located at
C:\Program Files (x86)\DevExpress 18.1\Components\Bin\Framework
and the .pdb files located at
c:\tmp\symbols
Using Nuget.Exe and the Credential Provider to push the packages to the feed
The Connect To Feed screen mentions I need to download Nuget.exe and the credential provider
Here are the docs on the Credentials Provider
I unzipped the VSTS CredentialProviders Nuget.Exe is included.
The next step is to follow the instructions given by the "add this feed" section of the Connect To Feed screen.
For example
nuget.exe push -Source "SBDDevExpress" -ApiKey VSTS c:\tmp\Nuget\DevExpress.Data.18.1.6.0.nupkg
I ran into an access denied issue that got solved here
then I was able to push all the packages I wanted.
Set the Nuget Package Source
In VS2017 with my solution open I used Tools -> Nuget Package Manager -> Package Manager Settings
I added package settings with the Azure endpoint set up as a package source.
Errors building
When I run the build pipeline I get errors like
The type or namespace DevExpress could not be found are you missing a directive or assembly reference?
From studying Updater.cs and Module.cs
It seems I am missing the following namespaces from the Nuget feed.
DevExpress.ExpressApp.DC;
DevExpress.ExpressApp.Updating;
DevExpress.Persistent.BaseImpl.PermissionPolicy;
[Update]
DevExpress suggested I compare the dlls generated in the bin folder with my package feed.
I found several missing files and pushed their packages.
I now have
XafMobile.Module\Properties\licenses.licx(1.0): Error LC0003: Unable to resolve type 'DevExpress.ExpressApp.ModuleBase"
I can see from the source code that ModuleBase is a public class in DevExpress.ExpressApp
I am wondering if this is something to do with reflection.
There is some mention of it at Dev Express support
[Update]
I tried removing the licence files and syncing the project.
Now the errors show as missing assembly references
Also When I rebuild my solution the license files are missing from the properties folders
I wonder if this helps explain it
[Update]
Manuel Grunder [DevExpress MVP] and DXNugetPackageBuilder author explained that
"
When working with nuget.packages you need to reference them via nuget as well
as he explains here
"
As is explained here
"When working with nuget.packages you need to reference them via nuget as well. Thats the reason why it did not work in the first place."
I am attempting to restore packages that I've uploaded to my AppVeyor account NuGet feed, yet it is failing to connect to the feed during the build.
In my appveyor.yml file I have:-
nuget:
account_feed: true
And I have confirmed that the account feed mentioned in the logs is the correct URL for my account feed.
I have also opened that feed by connecting to it using Visual Studio and entering my account credentials. When doing that, I have confirmed that the packages I'm trying to restore exist as expected.
However the build fails with this in the logs:-
https://ci.appveyor.com/nuget/xxxxxxxxxx-yyyyyyyyyyyy: Unable to load the service index for source https://ci.appveyor.com/nuget/xxxxxxxxxx-yyyyyyyyyyyy.
The HTTP request to 'GET https://ci.appveyor.com/nuget/xxxxxxxxxx-yyyyyyyyyyyy' has timed out after 100000ms.
NuGet Config files used:
C:\projects\MyProjectName\Source\NuGet.Config
C:\Users\appveyor\AppData\Roaming\NuGet\NuGet.Config
C:\ProgramData\nuget\Config\Microsoft.VisualStudio.Offline.config
C:\ProgramData\nuget\Config\ServiceFabricSDK.config
Feeds used:
C:\Users\appveyor\.nuget\packages\
https://www.nuget.org/api/v2
https://A-CUSTOM-EXTERNAL-NUGET-FEED-I-ALSO-ACCESS/nuget
https://ci.appveyor.com/nuget/xxxxxxxxxx-yyyyyyyyyyyy
C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\
C:\Program Files\Microsoft SDKs\Service Fabric\packages\
Note: The custom external NuGet feed should be unrelated. I have other packages that successfully restore from there before my build breaks with the private account repo attempt.
Is there something I'm missing that will allow me to connect to my AppVeyor account NuGet repo for the restoring of a package?
Could it have anything to do with the package itself?
AppVeyor has made some changes not allowing you to implicitly include your private account NuGet repository for public code respositories.
As in #ilyaf's answer, the discussion here confirms this, and says the following is the reason.
In previous implementation having this enabled and working for public
project was a vulnerability rather than a feature because on your
account feed you can have NuGet packages from both public and private
projects and anyone submitting PR to public build would have been able
to grab private packages from your account feed. It's fixed now.
So to still get this working, as mentioned in #Feodor Fitsner's comment, you need to configure a new nuget source mentioning your account's NuGet repo.
Here's what you need to do.
Go to the Project in AppVeyor that you're trying to build and select the Settings for that project. On the 'Environments' settings tab, add two new Environment Variables:-
'nuget_user'
'nuget_password'
...placing your AppVeyor credentials in the values for each of those.
In your appveyor.yml, add a new NuGet source under the install node.
install:
- nuget sources add -Name MyAccountFeed -Source <feed-url> -UserName %nuget_user% -Password %nuget_password%
...where <feed-url> is your NuGet feed URL.
Note: These two steps are defined in steps 2 and 3 or this doc.
https://www.appveyor.com/docs/nuget/#configuring-external-private-nuget-feed-for-your-builds
Now, ensure that you have account_feed and project_feed off for your build (otherwise the build will complain that there are duplicate feeds).
Do this by either deleting the following:-
nuget: account_feed:
OR ensure you have
nuget:
account_feed: false
project_feed: false
Your project should now build correctly, retrieving your NuGet packages from your NuGet account.
This, however, may be a workaround to what AppVeyor were trying to initially block with their change.
Please take a look at this discussion.
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.