MSBuild ignoring /p:BuildProjectReferences=false on Azure build server - c#

I've a solution with three projects in it: 2 C# WPF projects and 1 WIX project to create an installer. I've set up a build pipeline on Azure DevOps that references our own build server so I have access to the OS.
I want the Wix installer project to be dependant on the two C# projects for my local test builds but for the Azure Pipeline, I need to build the C# projects first and sign the executables before creating the MSI installer with the WIX project (that needs to be signed, too).
The problem is that the build server ignores "/p:BuildProjectReferences=false" (which should force msbuild to NOT build the dependencies) while my local computer does not when I run the exact same command line on both:
"C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\msbuild.exe" Solution.sln /p:AppxBundle=Always /p:UapAppxPackageBuildMode=StoreUpload /p:RunWixToolsOutOfProc=true /p:BuildProjectReferences=false /target:Installer /m:4 /p:Platform="x64" /p:Configuration="Release"
Extra info
I tried with and without Rebuild option (/target:Installer:Rebuild)
The build server fetches the git repository so it's exactly the same project on both sides.
Both Visual Studio installations are VS 2019 build version 16.11.14
Both Wix Toolset installations are version v3.11.2.4516
Any ideas how to get the build server to not build the dependencies?

Well this is embarrassing. Apparently I had some change on my local computer that wasn't committed yet. So code on both platforms wasn't the same...
The fix was a change in the *.sln file
Project("{930C7802-8A8C-48F9-8165-68863BCCD9DD}") = "Installer", "Installer\Installer.wixproj", "{A9EDFE69-D273-42EE-97EA-469C3434AEDC}"
ProjectSection(ProjectDependencies) = postProject
{C784B33D-1E8D-41EF-97C2-983CA9A5B693} = {C784B33D-1E8D-41EF-97C2-983CA9A5B693}
{B6E37FA9-64CF-491B-B268-9D115AABC6B2} = {B6E37FA9-64CF-491B-B268-9D115AABC6B2}
EndProjectSection
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "WPFProject1", "WPFProject1\WPFProject1.csproj", "{C784B33D-1E8D-41EF-97C2-983CA9A5B693}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "WPFProject2", "WPFProject2\WPFProject2.csproj", "{B6E37FA9-64CF-491B-B268-9D115AABC6B2}"
EndProject
I removed the 'ProjectSection' in the first project (Installer). This resulted in the code being built completely in Visual Studio but not for the Azure Pipelines because of the use of the /p:BuildProjectReferences=false param in the pipeline build command.
The two WPF projects still exist as depedencies in Installer project.
I hope this helps someone someday (or myself in a future project)

Related

Cannot find .NET 5.0 Console App project template in Visual Studio 2019

I'm currently trying to create a C# .NET 5.0 Console Application in Visual Studio 2019, and the option does not appear under project templates as I expect it to.
I downloaded Visual Studio Professional 2019 Version 16.9.4 (from https://visualstudio.microsoft.com/downloads/) and selected all workloads to be installed, then I installed SDK 5.0.202, ASP.NET Core Runtime 5.0.5, .NET Desktop Runtime 5.0.5, and .NET Runtime 5.0.5 (from https://dotnet.microsoft.com/download/dotnet/5.0).
When I go to File -> New -> Project and search for "Console Application", there is no default "Console Application" project template for C#. The closest I can find is "Console Application (.NET Framework)" for C#, VB, and F# and "Console Application" for C++. If I select "Console Application (.NET Framework)" for C#, the latest Framework that I can choose is ".NET Framework 4.8".
Actual Outcome: Project Templates
Actual Outcome: Frameworks
I compared notes with a developer who did not run into this problem, and they see the same framework restriction when they select "Console Application (.NET Framework)" for C#, but is also able to see the project template "Console Application" for C# (without ".NET Framework") and select ".NET 5.0 (Current)" as the target framework as expected. Nothing about what they installed and updated appeared to be noticeably different, our results for the command prompt command "dotnet --info" matched, and they did not have any "Installed products" listed under "About" or "Individual Components" listed under the installer that I was missing.
Expected Outcome: Project Templates
Expected Outcome: Frameworks
I have tried uninstalling and reinstalling everything, exhaustively installing every workload as well as additional individual components that looked potentially relevant, and making sure that the "Tools -> Options -> Environment -> Preview Features -> Show All .NET Core templates in the New project dialog (requires restart)" checkbox is checked.
Does anyone know what step I'm missing that is preventing me from creating a Console Application project template in C# using .NET 5.0?
Background -- This change/broke, issue that Microsoft opted deliberately you can read more here and the issue reported here but you can fix this with the 2 options listed below, i.e. A) enable it OR B) add it to VS via the repair tool
suggest clear VStudio Cache's -- kill dev process & clear cache before re/starting VS
run this cmd as admin in powershell
Get-Process devenv | Foreach-Object { $_.CloseMainWindow() | Out-Null }
Then DELETE ItemTemplatesCache, ProjectTemplatesCache folder ent. prof. etc.. C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE.
Now please Proceed with these Steps/Options
Option 1: you may have to enable this option...
Tools > Options > Preview Features > “Show all .NET Core templates in the New project dialog (requires restart)”.
Option 2: Install via Visual Studio Installer like so..
You can install missing workloads using the repair VS (this will also update the installer) and make sure you check the optional packages you want from the VS Installer tool please see this
after the installer starts check if the .NET Core workload is selected for desktop and console.. like below.. on the right pane you will need to check the correct boxes
Clear Visual Studio Component Cache (& optionally all Your templates)
Now, if you have already followed the above steps, then verifying you selected the checkbox of ".net-Desktop development" on top right is selected or not on Visual Studio installer: delete the cache and restore
i.e. you could restore the template in VS2017/2019 then try it again.
Kill dev process first run this Get-Process devenv | Foreach-Object { $_.CloseMainWindow() | Out-Null }
Please refer to the following steps:
DELETE the ItemTemplatesCache, ProjectTemplatesCache folder Ent. or Prof. version etc.. C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE. & C:\Users\<USERNAME>\AppData\Local\Microsoft\VisualStudio\16.0_93de0ddd
In the command prompt, navigate to the location of devenv.exe. This file is located in \Common7\IDE.
Type/Run this command devenv /installvstemplates and press Enter.
FYI - your templates cache is here, containing folders named after the zip files from your archives in the template folder.
you will need admin privilege's for edits/delete.
//templates cache Microsoft
%AppData%\Microsoft\VisualStudio\{some_version}\ItemTemplatesCache\
//templates path for verification, repair/reinstall or delete
%USERPROFILE%\Documents\Visual Studio 2019\Templates\ProjectTemplates
%USERPROFILE%\Documents\Visual Studio 2019\Templates\ItemTemplates
%ProgramFiles(x86)%\Microsoft Visual Studio\2019\<edition>\Common7\IDE\ItemTemplates\
%ProgramFiles(x86)%\Microsoft Visual Studio\2019\<edition>\Common7\IDE\ProjectTemplates\
Option 3: debugging your env. Template Config folder
Checking/Diagnosing the version:
run this dotnet --version
install the correct core version https://dotnet.microsoft.com/download/dotnet/5.0 more here
this dotnet new -u will tell you which templates are installed, you can uninstall, clear the packages cache, restart and reinstall with the repair tool.
Download and run collect.exe - https://aka.ms/vscollect - and share the log file created in %TEMP%\vslogs.zip with MS on github
FYI - This is what your template folder structure in visual studio should look like.
└───mytemplate
│ console.cs
│ readme.txt
│
└───.template.config
template.json
Eventually clear the MEF component cache, manually or with this extension.
But most likely something is wrong in the user cache at C:\Users\USERNAME\AppData\Local\Microsoft\VisualStudio\16.0_93de0ddd, which includes in particular InstalledTemplates.json and privateregistry.bin.
Try and rename (or delete) the folder, (or one the the two mentionned files to narrow the problem down), while VS is off, and restart VS. Only make sure that you have the proper workloads installed and the .net 5 from VS.
While it can be hard to tell what's exactly the issue with VS or local environment you have, it should be possible to temporary create projects with dotnet cli:
dotnet new console --output <project-dir>
If you would want to add it to an existing solution run
dotnet sln <solution-name>.sln add <project-dir>
The console app project file is very simple, so you can even create it manually, or create a project from any existing template and replace the contents with following asa workaround:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net5.0</TargetFramework>
</PropertyGroup>
</Project>
And maybe one more thing you could try is to run the VS installer as admin or ensure that it can install and access all the required components.
I checked and I am able to create dotnet5.0 console application with visual studio version 16.9.2 and SDK version 5.0.201. I think there is some installation conflict on your end. You can try uninstalling the SDK and reinstalling visual studio or updating it to latest version and downloading latest SDK. Also check if SDK is getting installed on your system under
C:\Program Files\dotnet\sdk[your SDK version]\
After a year of just dealing with it, I FINALLY FIGURED IT OUT.
Go to C:\Program Files\dotnet\templates then open every folder there. Apparently it was a permission issue because I was getting:
[Window Title]
6.0.6
[Main Instruction]
You don't currently have permission to access this folder.
[Content]
Click Continue to permanently get access to this folder.
[Continue] [Cancel]
After selecting Continue for each folder, everything started working.
The error that resulted from running dotnet new --list is what gave me the heads up.
My solution was deleting C:\Users\USERNAME.templateengine\
I have VS 2019 version 16.9.5 when I seen your post. I am using console app for my sample projects. I have tried it and able to achieve what you are looking for. I would recommend to update your VS to 16.9.5 and give it a try.
My VS 2019 version:
Creating Console app in VS 2019 16.9.5:
Finally it has created a console app project with target framework as .net 5.0

How can I make my project work with both v15.0 and v15.9 build tools?

We have two build servers and a newly created project has decided that it only wants to build successfully on one of them. It gives this error on the build server on which it fails:
MyLovelyNewProject.csproj(380,11): error MSB4226: The imported project "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\VisualStudio\v15.0\WebApplications\Microsoft.WebApplication.targets" was not found. Also, tried to find "WebApplications\Microsoft.WebApplication.targets" in the fallback search path(s) for $(VSToolsPath) - "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v15.0" . These search paths are defined in "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\amd64\MSBuild.exe.Config". Confirm that the path in the declaration is correct, and that the file exists on disk in one of the search paths.
Our DevOps guy investigated and determined that one server has the v15.0 build tools and one of them has the v15.9 build tools. The new project fails to build on the server that has the v15.9 build tools, since it's specifically looking for the v15.0 build tools.
All of our other projects build just fine on both build servers, but I wasn't able to find anything in their .sln or .csproj files that looked different from the new project. How can I retarget/reconfigure the new project so that it will build successfully regardless of which version of the build tools a given server has?
(If you want to suggest that DevOps synchronize the build servers to have the same version of the build tools, I agree! Alas, they're busy with a major server migration, and I would like the new project to not have a 50% chance of failing in CI while they're getting around to it.)
I think the issue is related to the Build Tool v15.9 rather than your projects. On that Server, you did not install the build workload for web projects on V15.9 Build Tool so that it cannot specify the web projects and lack the ability to build web projects. Or, the build tool is broken due to some reasons.
You could try the following steps:
1) try to open the vs_installer, click Modify
And select Web development build tools workload to install, also, if you have a asp net core web projects, do not forget to install .Net Core build tools workload.
To ensure this, I remove the web development build tools workload, and get the same issue for web project.
2) If it does not help, please click Repair for Build Tool V15.9 to repair it.

How to properly build MSI Setup Projects using Azure DevOps Pipelines?

I have been pulling my hair for the past couple days trying to figure out how set up a CI/CD process just to build a simple WPF solution and create the MSI setup file ("artifact") using Azure DevOps Pipelines. I have tried using Build VS Installer to accomplish this. My main problem is that I don't know exactly what am I doing wrong or what steps I am missing and I can't find clear instructions on this anywhere.
Here's what I've tried:
Using the Hosted 2017 agent pool and the basic .NET Desktop Template. Problems:
Create .msi file(s) from VS Installer project(s) as last task or before publishing artifact):
2018-11-28T22:57:56.3186071Z DEBUG: Aggregated: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\devenv.com
2018-11-28T22:57:56.3211382Z Now running (C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\devenv.com) with Arguments ("D:\a\1\s" /Build "release|any cpu" /Out "D:\a\1\b\BuildInstaller_Log_20181128225756.txt")
2018-11-28T22:58:54.0015320Z Done running DevEnv process. Success = True.
2018-11-28T22:58:54.1169279Z ##[warning]No .MSI files were found, please check your build-configuration. If this is expected, you might consider to use the default Visual Studio Build task instead of this custom Installer task.
2018-11-28T22:58:54.1434410Z ##[section]Finishing: Create .msi file(s) from VS Installer project(s).
Creating my own build agent as outlined in the documentation. I have Visual Studio Community 2017 with the VS Installer Projects extension installed on that server. I followed the steps from this related answer. Results:
2018-11-29T17:46:03.9813075Z DEBUG: Aggregated: System.Object[]\devenv.com
2018-11-29T17:46:04.4346060Z ##[error]Cannot retrieve the dynamic parameters for the cmdlet. The specified wildcard character pattern is not valid: System.Object[]
2018-11-29T17:46:04.4716416Z ##[section]Finishing: Create .msi file(s) from VS Installer project(s).
I also tried DevEnv Build from the market place instead of the DutchWorkz one and still couldn't get an .msi file. Can someone please show me some clear steps on how to achieve this simple goal?
I was able to figure out why I was getting the specific error message below and wanted to share in case it helps anyone out in the future.
DEBUG:
Aggregated: System.Object[]\devenv.com
[error]Cannot retrieve the dynamic parameters for the cmdlet. The specified wildcard character pattern is not valid: System.Object[]
The issue was that I had two versions (Professional and Enterprise) of Visual Studio 2017 installed on my private build server. Once I removed one of them, everything worked great. Not sure if there's a way to get it working with both installed, but I didn't need both.
Microsoft Visual Studio Installer Projects extension is present in windows-latest runner. Find more here
In short, use an agent with windows-latest vmimage and build via devenv.exe instead of MSBuild.

Microsoft.CSharp.Core.targets missing

I am building a webservice project on a TFS2017 Update 3 with build tools 2017. I get the following error
C:\Program Files (x86)\Microsoft Visual
Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.CSharp.CurrentVersion.targets(322,5):
Error MSB4019: The imported project "C:\Program Files (x86)\Microsoft
Visual
Studio\2017\Enterprise\MSBuild\15.0\Bin\Roslyn\Microsoft.CSharp.Core.targets"
was not found. Confirm that the path in the declaration is
correct, and that the file exists on disk.
What steps do I need to take to fix this error?
In my case, opening the existing Solution file (with .sln extension), it installed all the missing dependencies.
Otherwise check for missing target packages at nuget.org manually and install them (e.g. MSBuild.Microsoft.VisualStudio.Web.targets).
As per this GitHub issue, you'll need to set $(RoslynTargetsPath).
If MSBuild is installed on the machine and your tests run in a Visual Studio Developer Command Prompt, then you shouldn't need to do anything. However, MSBuild 15.0 no longer places itself in the registry which makes it impossible for MSBuild to find itself. This is because of a mandate by Visual Studio where you can have multiple side-by-side installations. MSBuild in this case would be installed once per Visual Studio instance. MSBuild now finds itself by looking at environment variables set by the VS command prompt.
If you want to fully redistribute MSBuild via a combination of our packages and all of the other packages needed to do full project evaluation, you will have to set RoslynTargetsPath before you load projects. You could argue this is an issue with NuGet since all packages' <contentFiles /> go to the the root of your output directory and you can't specify a subdirectory for certain packages.
If you're coming to this page from google/duckduckgo after trying to figure out why you're getting a similar message in Ubuntu 20.04, maybe this can help: https://askubuntu.com/a/1231973/1073658 (tl;dr apt install mono-roslyn from mono-project's repo)
First suggest you directly use msbuild command on the build agent with TFS build service account. This will narrow down if the issue is related to your agent environment or your TFS build definition.
According to your error info, the path C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Roslyn\Microsoft.CSharp.Core.targets is looking the path of Visual Studio 2017.
However, for Build Tools the path is different should be C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\Roslyn
Seems you haven't installed VS2017 on your build agent. This maybe the root cause of the issue.
The simplest solution is installing VS2017 on your build agent. Note, you need to reconfigure the build agent or restart build agent service to capture those new capabilities. Otherwise you need to change the corresponding import section in your .csproj project files.
I updated to TFS2018 and the problem got solved.

InstallShield installation has different Current-Directory to Deployment installer

my C# application built using Visual Studio 2010 had a deployment project which was being used to build an .MSI installer. Since we know we'll need to upgrade VS pretty soon and we know that later editions won't support the .vdproj, I've started to rebuild the installer using InstallShield.
Both the old and the new installers install the application in Program Files, but when I run the resulting executables the version created using InstallShield seems to start with a different current directory setting.
If I run the installed executable using our old installer (vdproj) and get it to output the current directory it returns:
C:\Program Files\MY_APPLICATION
...which makes sense since this is the folder in which the application is installed. But if I run the installed executable created by the InstallShield installer, the result of Directory.GetCurrentDirectory() is always:
C:\Documents and Settings\USERNAME
Now, I know I can just set the current directory on start-up, but I was wondering whether there was just some kind of setting in InstallShield I could use instead.
Many thanks in advance.

Categories

Resources