I am not able to build a UWP project with Github actions. I run dotnet build --configuration Release on the whole solution, but for UWP the error is:
error MSB4019: The imported project "C:\hostedtoolcache\windows\dncs\3.1.101\x64\sdk\3.1.101\Microsoft\WindowsXaml\v16.0\Microsoft.Windows.UI.Xaml.CSharp.targets" was not found. Confirm that the expression in the Import declaration "C:\hostedtoolcache\windows\dncs\3.1.101\x64\sdk\3.1.101\\Microsoft\WindowsXaml\v16.0\Microsoft.Windows.UI.Xaml.CSharp.targets" is correct, and that the file exists on disk.
Locally I use VS 2019 Pro, 16.4.5. I have this import in my csproj (generated by default VS template):
<Import Project="$(MSBuildExtensionsPath)\Microsoft\WindowsXaml\v$(VisualStudioVersion)\Microsoft.Windows.UI.Xaml.CSharp.targets" />
I tried installing the visualstudio2019-workload-universal with chocolatey, but same result.
Links to Build, yaml, csproj
Any idea how to fix the build issue?
Related
I have a roslyn analyzer project based on Microsoft's default template. I can easily build the analyzer in Visual Studio or with msbuild.
The problem is that the solution includes a vsix project that relies on the microsoft.vssdk.buildtools which are not supported by dotnet build.
This results in an error message when trying to build the solution in the command line with dotnet build: microsoft.vssdk.buildtools\17.4.2119\tools\VSSDK\Microsoft.VsSDK.targets(826,5): error : VSIX deployment is not supported with 'dotnet build'
The vsix is nice to have when developing with Visual Studio, but I do publish my analyzer via NuGet package instead of as vsix so I don't need the vsix on the CLI.
Is there a way to specify in the csproj that I don't want it to be built when it is invoked from dotnet build? I'd like to avoid having a separate sln file or a specific dotnet configuration that excludes the project if possible.
Two possible approaches include using a solution filter and changing the project to not build under certain conditions.
Use a Solution Filter
dotnet build will accept a solution filter file (.slnf).
To create the solution filter:
Open the solution in Visual Studio
Go to the solution explorer window
Right-click on the VSIX project, choose 'Unload Project'
Right-click on the solution, choose 'Save As Solution Filter'
When building with dotnet the .slnf will need to be used. Using the .sln file or the VSIX project file with dotnet will be an error.
Detecting when Invoked from dotnet build
There isn't a defined property or function in MSBuild that identifies the executable that is running the MSBuild engine.
However there is a MSBuildRuntimeType property.
Prior to MSBuild 15, MSBuildRuntimeType will be undefined. In MSBuild 15 and later MSBuildRuntimeType will have a value of Full, Core, or Mono. From the documentation MSBuildRuntimeType will have a value of Core when dotnet build is used. (Further the error message "VSIX deployment is not supported with 'dotnet build'" is only displayed when '$(MSBuildRuntimeType)' == 'Core'.)
There isn't an 'exit build' task so the project can't detect and then end. We need to detect before the project really starts. But wrapping a project within a project is clunky especially if you want to be able to work with the project and change properties from the Visual Studio IDE.
Targets can be redefined and an Import can have a condition. A file can be imported when MSBuildRuntimeType is Core and the file can redefine the 'Build' target.
Add to the VSIX project file:
<Import Project="noop.targets" Condition="'$(MSBuildRuntimeType)' == 'Core'" />
The noop.targets may contain the following:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="Build">
<Message Text="$(MSBuildProjectName) has been skipped." />
</Target>
</Project>
Hope this helps or at least provides some ideas.
I have wpf project
for Framework .NET Framework 4.7.2
Build Any CPU
Previous Build was allways without problem.
After i opened the project from a new installation of visual studio 2022
I always get:
Problem generating manifest. Could not load file or assembly
'D:\Source\Repos..Toolbox.exe' or one of its dependencies. An attempt
was made to load a program with an incorrect format.
I Just tried:
Build Setting PlattForm Target differnet values
Nuget Package Manager Package Manager Console update-Package -reinstall
i added:
<PropertyGroup>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
</PropertyGroup>
I have some References but nothing special. To get sure i reinstalled
RestSharp.
Is there a way to find out which reference throws the error during creation of the Manifest?
Solution had nothing to do with Visual studio.
A virus scanner detected the new created .exe file and removed it.
The Error message from Manifest creation was missleading. The file was simply missing in the directory when generating the Manifest.
We have a Visual Studio 2013 project who's .csproj looks like this
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
Recently we migrated the solution to Visual Studio 2017 but somehow tool version remained same.
I am using TeamCity to build my project & on teamcity server we only have MS build version 14. If I use it to build the app, I get following error: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
What is the easiest way to update the tool-version is .csproj? If I update it manually, would it cause any issues? are there any other settings/config I need to change once I make this change?
ToolsVersion is not the main cause of this issue I think, so you can feel free to manually change it. And for project from VS2013, its ToolsVersion should be 12.0 instead of 4.0.
VS2013=>12.0, VS2017=>15.0, VS2015=>14.0: So you now have one project migrated from VS2012 to VS2017, and now you use msbuild of VS2015 to build it. For this scenario, here're some suggestions which may help:
1.Change the ToolsVersion to 12.0(or 14.0). This actually makes a bit effect.
2.Make sure you've installed web application workload for your msbuild 14.0 in server. If your msbuild 14.0 comes from VS2015, please check if you can create new web application project in it, then you'll know if you've installed web workload in VS! (The missing targets come from the web app workload, similar issue see here.)
If you can find the missing file in C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\WebApplications, trying passing /p:VisualStudioVersion=14.0 to msbuild command when you configure it in teamcity.
3.The most recommended way is to install the msbuild from higher VS version. MSbuild has independent package for VS2017 and VS2019.(Build Tools for VS2017 or VS2019)
You can find their download link here,see Tools for VS category. You can install this package(Enable web-related workload!) in your server(you don't need to install whole VS IDE), and then you can call msbuild.exe from C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin or C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin in teamcity to build current project.
Note: MSBuild from higher VS version can always build projects from earlier VS versions, but msbuild from earlier sometimes can't recognize projects from higher vs versions. So it's recommended to use msbuild 15.0 to build projects from VS2017, instead of using msbuild 14.0.
When I try to build my .csproj file with dotnet it throws an error, but when I build project at Visual Studio 2019 it succeeds.
I need to build with dotnet because my Azure pipeline job uses it.
This is the error:
dotnet build MyProject.Mobile.Droid.csproj --configuration Release --force
MyProject.Mobile.Droid.csproj(584,3): error MSB4019: The imported project "C:\Program Files\dotnet\sdk\3.1.100\\Xamarin\Android\Xamarin.Android.CSharp.targets was not found. Confirm that the expression in the Import declaration "C:\Program Files\dotnet\sdk\3.1.100\\Xamarin\Android\Xamarin.Android.CSharp.targets" is correct, and the file exists on disk.
Build FAILED.
(Also as a screenshot.)
If I set the path parameter in my .csproj to this:
<MSBuildExtensionsPath>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild</MSBuildExtensionsPath>
Then the error changes:
The reference assemblies for MonoAndroid,Version=v1.0 were not found. To resolve this, install the Developer Pack (SDK/Targeting Pack) for this framework version or retarget your application. You can download .NET Framework Developer Packs at https://aka.ms/msbuild/developerpacks
Any suggestions on how to solve this?
You'll need to use msbuild (like msbuild MySolution.sln) to build a Xamarin project today.
You can build the individual netstandard2.x projects using dotnet build, however the Mono based platform projects (i.e. the Android and iOS projects) need to be built using msbuild.
Try setting the TargetFrameworkRootPath to where you have xamarin installed.
<TargetFrameworkRootPath>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\ReferenceAssemblies\Microsoft\Framework\</TargetFrameworkRootPath>
or on the command line
dotnet build -clp:ErrorsOnly -p:MSBuildExtensionsPath="C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/MSBuild"/ -p:TargetFrameworkRootPath="C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/ReferenceAssemblies/Microsoft/Framework/"
I have a build process on Azure DevOps that I have been building successfully for awhile now.
Recently one of my developer added a page that contains the MVC library
using System.Web.Mvc
However, the build keeps failing now when I build it via the Azure DevOps build agent as part of our CI/CD process.
ClassName.cs(5,18): Error CS0234: The type or namespace name 'Mvc' does not exist in the namespace 'System.Web' (are you missing an assembly reference?)
It compiles if I compile manually using Visual Studio 2017 on my own laptop or if I use the Visual Studio 2017 on the build machine where the Azure DevOps build agent runs.
The steps that I've tried to troubleshoot:
Ensure in my Project's NuGet, that I have Microsoft.Aspnet.MVC latest
vesrion.
I've tried to reinstall Microsoft.Aspnet.MVC on the build
machine through NuGet
I verified my project' default package
management format is : Packages.config
I verified that my
packages.config has < package id="Microsoft.AspNet.Mvc" version="5.2.7" targetFramework="net472" />
I tried to reinstall all
the package on my build machine by running Update-Package
--reinstall command.
I verified that on the build agent machine I have the Microsoft.AspNet.Mvc folder and all of its dlls under repositoryPath -
$(Solutiondir)/packages and globalPackagesFolder -
$(UserProfile).nuget\packages
I'm running out of idea on why it compiles on Visual Studio manually but has error when I compile using the build agent through MS Build on x64 bits.
I have tried to reproduce your bug by comparing two new ASP.NET Web Application (.NET Framework) projects, one created with an empty template and the other with the MVC template. The MVC project comes with the System.Web.Mvc reference and the empty one does not, so I have come up with additional troubleshooting steps while manually adding the reference to the empty project.
Make sure the project file that is failing to build includes a reference to the Microsoft.AspNet.Mvc package which includes a path (use your latest version)
<Reference Include="System.Web.Mvc, Version=5.2.4.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<Private>True</Private>
<HintPath>..\packages\Microsoft.AspNet.Mvc.5.2.4\lib\net45\System.Web.Mvc.dll</HintPath>
</Reference>
You can copy this and it from a newly created MVC template. An implicit reference <Reference Include="System.Web.Mvc" /> will only work if build artifacts were generated before which could be a good reason for a build succeeding in development and failing in the build pipeline.
Clean the solution, close Visual Studio and delete all bin and obj folders to make sure your build is not succeeding because of previous ones and Visual Studio does not regenerate them.
Use the Developer Command Prompt to call msbuild.exe in the project folder, this will be a more similar environment to your build pipeline than building with Visual Studio