I have ClickOnce app and I want to generate .application file for every version without manifest. I've set
<PropertyGroup>
<NoWin32Manifest>true</NoWin32Manifest>
</PropertyGroup>
In the project file, but when building through Azure Pipelines with MSBuild there is no .application file for the version generated
I've also tried to set /p:NoWin32Manifest=true but still nothing.
Why is that?
NoWin32Manifest this property applies only to Visual Studio projects targeting Windows Vista. In projects deployed using ClickOnce and Registration-Free COM, this property is ignored.
This is stated in this official document.
Related
According to Microsoft, using global.json is the correct way to publish with a specific minor version. However, i have searched the documentation but cannot find to include the file after creating it in Visual Studio 2022 when publishing the project. How can this be done?
From the docs:
The global.json file allows you to define which .NET SDK version is used when you run .NET CLI commands.
That is, when you build your app.
If you want to specify the runtime version instead of the SDK version, you should use target frameworks.
If you do want to specify the SDK version used to build the app, you could manually create a global.json file and add it to the current working directory as explained in the docs. The Publish wizard in Visual Studio won't do this for you.
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.
I have ASP.NET Core C# web application. I made some changes that now use C# 7.1 features. I changed project version, so it compiles and runs fine. However, when I try to publish the project, I am getting an error:
Feature 'default literal' is not available in C# 7.0. Please use language version 7.1 or greater.
Compile command that I see is:
C:...\.nuget\packages\microsoft.net.compilers\2.6.1\tools\csc.exe /noconfig /unsafe- /checked- /nowarn:1701,1702,1705,1701,1702,2008 /nostdlib+ /errorreport:prompt /warn:4 /define:TRACE;RELEASE;NETCOREAPP2_0 /errorendlocation /preferreduilang:en-US /warnaserror+:NU1605`
As suggested elsewhere, I installed Microsoft.Net.Compilers (v2.6.1), but it didn't make any difference.
Is there a Visual Studio setting that affects publish specifically?
UPDATE: Looks like a console application doesn't have this problem. If it builds successfully, it publishes successfully as well. However, the web application does not publish. Was anybody successful in publishing ASP.NET Core web application with C# 7.1 features?
Adding <LangVersion>latest</LangVersion> to your .pubxml file made it possible for Visual Studio 2017 (15.5.2 in my case) to publish.
Source: https://developercommunity.visualstudio.com/solutions/166543/view.html
Update:
After upgrading my VS2017 from version 15.4.5 to 15.5.2 I can reproduce the problem, and I get an error
Feature 'default literal' is not available in C# 7.0. Please use
language version 7.1 or greater
The answer from #Jeremy Cook solves the issue:
<LangVersion>latest</LangVersion> in .pubxml
In both old and new project formats the LangVersion element in project file is responsible for this.
You can either change that via csproj xml file or via UI in visual studio.
Please note that this setting is dependent on your build configuration.
To make sure that you can both code and publish using C# 7.1 and later make sure you configure this setting regardless of build configuration (Debug, Release etc).
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<LangVersion>latest</LangVersion>
</PropertyGroup>
</Project>
For MAC users, I did spend a long time finding out. Here's what has worked for me.
Right-click to your main .csproj file and click 'Edit Project File' to open it.
Then, inside the ... add the line latest and save it.
That's it!
Run your code and it should work ok from now on.
If you are migrating from ASP.NET Core 2.0 to ASP.NET Core 2.1 make sure you have line
<TargetFramework>netcoreapp2.1</TargetFramework>
in your .pubxml file.
It seems you are published to your local Nuget store. Ensure that the Nuget store is configured to use C#7.1. And also check whether your Nuget.exe pack is updated to the latest that can use C#7.1
When I build my .NET Core 2.0 console app, I move it over to the server and I then try and run it. I am getting the error "An assembly specified in the application dependencies manifest..."
I add the dlls to the local folder that it is searching for, but it ends up still needing system dlls like Data.SqlClient.
How do I build the project where it includes all the dependencies in the output files? I've published the project with Visual Studio 2017, however, it still says things are missing when I copy all those files over. I've tried building and publishing with VSCode and have the same problem.
I faced a similar problem. When I deployed my application in host environment and executed with dotnet command like "dotnet myapp.dll" it worked fine using the host environment's .NET Core runtime.
But when I packaged the same application as a Standalone application with an .exe file included to start the application, I faced this error for Newtonsoft.json Nuget Package when .exe file is executed.
My observation is as below, and I was able to solve the problem accordingly.
Framework-dependent deployment:
If the application uses third-party libraries and intention is to use the .NET Core runtime in the host environment, then the checkbox in the "Manage Packages for Solution" has to be checked in the Nuget Package Manager (as shown in the screenshot).
Self-contained deployment:
If the published application is supposed to be a stand alone application in the host environment (even with an .exe file), then the application's .csproj file should include the RuntimeIdentifiers (.NET Core RIDs) specified. Also the third party libraries have to be included in PackageReference. For example,
Reference: https://learn.microsoft.com/en-us/dotnet/core/deploying/deploy-with-vs
You need to publish the application to have all the dependencies included
I have a net core consoleapp project, as follows (VS 2017 style):
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp1.1</TargetFramework>
<Version>2.0.0</Version>
<AssemblyVersion>3.0.0.0</AssemblyVersion>
<FileVersion>4.0.0.0</FileVersion>
<RuntimeIdentifiers>win10-x64</RuntimeIdentifiers>
<RuntimeFrameworkVersion>1.0.4</RuntimeFrameworkVersion>
</PropertyGroup>
</Project>
I can build the project without any issues, I can publish it using dotnet publish -r win10-x64 and it will generate an exe file together with the dll file. My problem is that the exe file has some strange FileVersion and ProductVersion fields (in my case FileVersion = 1.0.1.4500 and ProductVersion 1.0.1.cee57... (some guid)). Also the rest of the file details (name, copyrights) are related to dotnet instead of my own project.
Is there any way I can control the exe details when publishing?
No, the main build output of your project still is a .dll file, the .exe (or linux, mac executables) file is a copied and renamed dotnet.exe (or in case of upcoming 2.0 versions, apphost.exe with the dll name to run embedded).
The exe file is only a helper that boots the runtime and then loads your dll. However, you can try to use binary editing tools like editbin.exe (VS C++ Tools) to modify the file after publishing.
Dotnet core 3.0 added the functionality of versioning the shim exe during publish, like OP was expecting. It should work out of the box now. However that feature does not function if running builds on a Nanoserver based docker environment.
warning NETSDK1074: The application host executable will not be
customized because adding resources requires that the build be
performed on Windows (excluding Nano Server)