Is it possible for a dev team to utlize nuget when the repository is available and fallback to an included assembly folder when the repository is not available?
E.G. Our dev team has access to a nuget repository, so when we update our nuget packages from the repo that is not available to the deployment team, we would want to update the included assemblies with those assemblies...and allow the build/deployment team to fallback to the included assemblies.
You can use a shared folder on your network as a backup repository.
Simply pick a shared folder that everyone, and the build server's user account, has access to.
Then, add a new package source pointing to this folder
Lastly, make sure that whenever you update a nuget package, you drop a copy of it in this backup folder. A simple script could do this for you.
Related
https://github.com/unoplatform/Uno.Telerik.UI-For-UWP is there a nuget for this repo?
I couldn't find any on nuget and Telerik.UI.for.UniversalWindowsPlatform is not support on mobile projects. Thanks.
[Update 2]
I am no longer continuing development on this and instead focusing my efforts on Telerik UI for MAUI.
[Update]
I am working on making this available for the Uno community. You can find it on nuget.org at xxx
[Original]
Telerik doesn't own that fork, so they do not publish a NuGet package for it.
If you would like to have a NuGet package, you can clone the repo locally and compile it yourself. See the Getting Started section of the README to lean how to compile the repository.
Generate NuGet Package
Once it is compiled, you can generate a .nupkg file (see number 6):
Make sure you have the required software to build UWP applications
Clone a copy of the repository code
Open UWPControls.sln located in Controls folder and build it
Open UWPMap.sln located in Controls folder and build it in x86/x64 and ARM configs
All binaries are now located in Binaries folder
You can additionally build a NuGet package by running BuildTools/BuildNuGet.bat. The generated package will be located in the NuGet subfolder.
Next Steps
Once you have your own nupkg file, you can put it in a Package Source (i.e. just a local folder) or put it in your own nuget feed server and list that as a packages source.
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 need to update package repo before building a solution in TFS Build Definition. I want to implement this using CommandLine build task.
Could someone tell me how to write a command to update package repo using a path.
According to your prior question, there are just missing some external packages during your TFS build pipeline.
Usually TFS use Package Management that hosts NuGet, npm, and Maven packages alongside all your other TFS assets: source code, builds, releases, etc, also be able to handle the external packages.
You could directly add external packages to a TFS Package Management feed. When you restore the packages, select the feed. All need packages will be restored entirely. To achieve this, just use Push NuGet packages to specify the packages you want to publish and the target feed location.
More details please refer Get started with NuGet Package Management in TFS
I have certain packages that are not available online. I am maintaining a package folder in my repo that holds all the packages required for the application to successfully build.
I am trying to figure out a way to install packages in VSTS build definition from the packages present in repo.
Thanks in advance.
I recommend that you can store your packages in VSTS package feed. Then restore the packages from your VSTS feed.
Publish your packages to your VSTS package feed. (Refer to Package Management in Team Services and TFS)
Edit your build definition, specify config file for Nuget restore step or put NuGet.config at the solution root, next to the project.json file.
Regarding packages store in the repository scenario, you can clone that repository to the corresponding folder by using Command Line step/task;
Edit your build definition
Select Options
Check Allow Scripts to Access OAuth Token
Add Command Line step (Tool: [git tool path] (you can add nuget.exe to environment (system) variable), Arguments: clone https://:$(System.AccessToken)#[git repo url], Working folder: [folder that packages need to download]
On the other hand, if the project/solution file and package files are in the same repository, you just need to select corresponding repository in Repository tab of build definition.
We're using FluentMigrator (a NuGet package) on an ASP.net/MVC project to maintain database changes to our SQL Server.
What is the "correct" way to distribute a NuGet package with other build artifacts for usage during a deployment? Do I only need the "packages" folder?
I'm hoping for a response other than "use package manager and install the Nuget package on PROD".
I don't want to pull the package (from either local or non-local sources) during deployment, I want to include the correct package with my compiled code.
The correct way is to pull the package down before building the project, then assuming your project references the assembly such that Copy Local is true, it will be included in the build output, which should be stored as an artifact in your CI tool.
You definitely should not be doing anything related to NuGet beyond this point in your build/deployment process.