I need to integrate an older VS2008 project for WINCE6, without .NET, into an AzurePipline. This works very well with msbuild. Now I am looking for a way to set the version number in the version info.
Ready-made extensions did not work with the old project.
Probably the best way is to use a property of msbuild. I just don't know how to process the version number in the project.
Has anyone ever done something like this? Thanks for your suggestions.
In your build pipeline on Azure DevOps, you can add an Assembly Info task to set assembly information of your application.
Here I find some Assembly Info task extensions from the Marketplace. You can install one suitable extension from them to your organization and then call the related task in your build pipeline.
Below is a similar topic as reference:
https://stackoverflow.com/a/8452320/14697693
Related
I try to add a nuget package reference automatically to a visual studio project if needed, with the help of a roslyn code fixer.
Since the "CodeFixProvider" is not a "Microsoft.VisualStudio.Shell.Package" there is no GetGlobalService Method to retreive a "IComponentModel" in order to get the "IVsPackageInstaller2" service.
Is there another or an even better way to add a nuget reference to a project?
I am a bit lost here after days of googling.
Thanks in advance!
I have a build pipeline configured for a Service Fabric solution on Azure DevOps like this:
Everything was fine until a few days ago when the build started failing on a particular build agent (private), with the following error (for a few projects):
C:\Program Files\dotnet\sdk\2.1.200\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(327,5): Error : Assets file 'F:\Agent03\w\84\s\src\MyProject.Sam.Tiles.Domain\obj\project.assets.json' not found. Run a NuGet package restore to generate this file.
The failing task is the Build solution $(PathToSolution) one.
The weird thing is that the build fails when running on some agents but with others the build is fine.
Some details:
Use NuGet 4.x task started using NuGet v4.9.1 very recently, I think. I tried using v4.8.1 with no luck;
Most of the projects use the PackageReference format, but the .sfproj project uses the packages.config file
I tried using the dotnet restore task but there is an error when trying to restore the packages for the .sfproj project:
`Error : Unable to find the
'....\packages\Microsoft.VisualStudio.Azure.Fabric.MSBuild.1.6.7\build\Microsoft.VisualStudio.Azure.Fabric.Application.props'
file. Please restore the
'Microsoft.VisualStudio.Azure.Fabric.MSBuild' Nuget package
Any idea on what might be causing this issue?
Some of the projects use the PackageReference format but the .sfproj project uses the packages.config file.
I still don't understand why the build started failing, but I was able to find a workaround. Given that PackageReference is not yet supported in Service Fabric projects, my workaround was to use both restore tasks as follows:
My problem turned out to be a solution that didn't include all the necessary projects.
I have a master solution file that includes all my projects, and a number of smaller solution files with only some of the projects. The master solution built fine in Azure DevOps, but the partial solution failed.
I realized that the missing project.assets.json file belonged to a project that needed to be included in this failing solution.
Trevor's comment on 2/20 gave me the clue. You likely don't have the complete set of projects referenced by the solution. (ProjectReferences may go to other projects, which are not in the solution).
Here is why this crazy workaround (run dotnet.exe and nuget.exe restore tasks) worked:
dotnet restore will walk project references by default to ensure they are restored also.
--no-dependencies switch can turn that off.
nuget.exe restore has the opposite default, because we didn't want to break old users.
-recursive can turn this on.
The right solution is to make your solution contain all the projects.
-Rob Relyea
NuGet Client Team, Engineering Manager
Having trouble getting MSBuild/Visual Studio 2012 to deploy a CRM 2011 Plugin Assembly to a named CRM Solution.
I've 2 project/SLNs. In one, I can precisely control which CRM Solution the build deploys a Plugin Assembly into; my msbuild (call this build-1) creates a CRM Solution with my custom entities/forms and Plugins. In another, despite specifying the exact values via msbuild /p for CRMOrganization, CRMSolutionName, CRMDiscoveryServer, 'CRMDiscoveryServerScheme, the resulting CRM Solution contains only the entities/forms. The Plugins are deployed but placed incorrectly into the Default Solution (call this build-2).
I've created build-2 from copy/pasting the values (except SLN and Project names) from build-1...and am at a loss to understand why build-1 deploys the plugins to my named CRM Solution, but build-2 deploys them to the Organization's Default CRM Solution.
Any ideas?
CRM might look specifically at Display name instead of Schema Name as the solution Name.
Unfortunately the CRM Developer Toolkit in both VS010 and VS2012 versions is configured at the solution level only. Therefore, despite adding multiple projects to your solution they will both use the CRM Organisation settings at the solution level. It's a rather annoying limitation that's existed since the first release of the tooling I'm afraid.
The MSBuild target file used by VS (Microsoft.CrmDeveloperTools.CrmClient.target) is available at the default install location C:\Program Files (x86)\MSBuild\Microsoft\CRM. This folder also includes the supporting assembly containing the MSBuild Tasks if you felt like rolling your own build target.
I've looked at this briefly myself in the past but a word of warning, many of the classes in that assembly are sealed so extending them is off the table.
I'm having a .net WPF project that compiles to a bunch of dlls. I also have another project that compiles all the dlls and creates an installator exe.
I am also using TeamCity to automatically do those tasks for me with a press of a button.
The problem is that I want to have a separate TeamCity build configuration intended to automatically copy the result installator exe to a number of remote machines, each having specific credentials. But, unfortunately, I don't get how do I do this.
I have found some articles on automatic deploying (like this http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity.html), but, obviously, they are very specific for web projects.
So, how should I correctly deploy my installator on build?
Your best bet is to research NAnt and make a simple task that will copy the TeamCity artifact (installer) out to the specified location.
All you would need to do is have TeamCity execute the specified NAnt task after the installer has been built.
http://nant.sourceforge.net/release/0.85/help/tasks/copy.html
Update
Also, check out this question for solutions on specifying the credentials for the copy task.
OK, I've found out that it's pretty easy to do this using the FtpUpload MSBuild community task. There, one can set up the credentials and all other stuff needed for uploading a file (or a set of files) via ftp.
I'm currently looking at NuGet to solve my dependency problems in TFS and what I wanted to do is to host my own NuGet server that would take care of internal dependencies. I also want to use NuGet to handle my 3rd party dependencies as well. I'm trying to set up automated builds for our company and this is one roadblock I'm trying to overcome with NuGet.
So my question is how do I handle this scenario in which I have to retrieve my dependencies from different servers?
Is there a better way to handle internal dependencies? How is everyone else doing this?
Also just as a note I intend on using NuGet without committing packages to TFS. I planned on using the method outline in this article:
http://blog.davidebbo.com/2011/08/easy-way-to-set-up-nuget-to-restore.html
Glad you're looking into the no commit scenario for NuGet packages on TFS. You can take a look at my blog post on this topic where I explain the concept.
EDIT (2012/06/13): NuGetPowerTools is replaced by NuGet's built-in package restore functionality. However, same concept of changing the PackageSources element in nuget.targets still applies.
You definitely should take a look at David Fowler's NuGetPowerTools.
After installing this package, you can Enable-PackageRestore (newly installed command in Package Manager Console), which will add...
Enabling package restore will add MSBuild targets to your project files. These MSBuild targets will trigger nuget.exe in a pre-build step and fetch any packages required by your project.
No need to check-in NuGet packages in source control, all you need is the packages.config and these msbuild tasks.
To configure multiple, different package sources, you need to set some settings to be used by these MSBuild tasks. One of them is PackageSources. You can set it by editing the NuGet.targets file, which you will find in the .nuget folder once you enabled package restore.
Regarding those package sources, you could set up different internal NuGet galleries, or simply set up different network shares to be used. This is a matter of requirements and preference, so you can choose. All you need to do, is to tell your msbuild targets to use these packagesources. The order in which you define them, will be the order of lookup of packages as well.
Good luck!
Xavier
Little update on accepted answer and question:
When using TFS as a buildmachine without visual studio installed on it, you can do the following so the buildmachine automatically uses your custom packageSources (more than 1 in the same solution) without any further configuration of packagesources in your solution.
Create a machine default config by placing a NuGet.Config in the root ( C:\NuGet.Config ) by using sample from: http://docs.nuget.org/docs/reference/nuget-config-file
Comment out the line with: <add key="repositorypath" value="$\External\Packages" />
Otherwise your packages gets expanded in C:\$\External\packages\'. When commented out, the config gets chained and the right directory will be used.
Config your needed packagesource(s).
For more Info about other options (e.g. user specifc) see: http://docs.nuget.org/docs/reference/nuget-config-file (bottom of the page).