Global tool name change - dotnet-mage

Global tool has been renamed from Mage.NET to dotnet-mage

Details

Microsoft.DotNet.Mage package (https://www.nuget.org/packages/Microsoft.DotNet.Mage) contains Mage global tool, which can be installed using dotnet tool install command.

First version of the package (5.0.0-rc.2.20513.1) contained Mage tool with the old name Mage.NET.

Starting with package version 5.0.0-rc.2.20527.1, the tool name is dotnet-mage.

Examples

The tool can be installed using the following command:

dotnet tool install --global microsoft.dotnet.mage --version 5.0.0-rc.2.20527.1

After installation, the tool can be run using either of the following commands:

dotnet-mage
dotnet mage

More examples and documentation are available at: https://github.com/dotnet/deployment-tools/tree/master/Documentation/dotnet-mage

It would be valuable if .NET 5 applications, deployed by ClickOnce, could gain access to URL parameters, specified by the user in the app activation URL.

.NET FX applications could use ApplicationDeployment class to obtain URL parameters: https://docs.microsoft.com/en-us/dotnet/api/system.deployment.application.applicationdeployment.activationuri?view=netframework-4.8

This method is not available to .NET 5 applications as ApplicationDeployment class does not exist.

However, Launcher is a .NET FX application and has access to ActivationUri property.

One solution is for Launcher to obtain URL parameters and persist them to a Json file that would be read by .NET 5 application. This would follow the proposed solution for the similar issue: #27

I typically deploy to an internal unc share for my app, but recently the server I use was down and I didn't know it. When I went to publish my updated project to the share, VS2019 would hang and never respond back, it just kept the spinning icon. Shouldn't there be some kind of timeout for unavailable / unreachable unc paths?

I have WPF application. I have migrated it to .NET 5 and it works, great. My app uses ClickOnce to release new versions. The ClickOnce publish process will fail when the solution contains projects with different target frameworks.

To simplify the problem please create one empty WPF application in .NET 5 (target framework: net5.0-windows) next add library project to this solution in .NET 5 (target framework: net5.0). Now try to publish the project. You will receive an error like this:

2>------ Publish started: Project: WpfApp123-net5, Configuration: Release Any CPU ------
2>It is no longer necessary to use the Microsoft.NET.Sdk.WindowsDesktop SDK. Consider changing the Sdk attribute of the root Project element to 'Microsoft.NET.Sdk'.
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Pro Preview\MSBuild\Current\Bin\Roslyn\csc.exe /noconfig /unsafe- /checked- /nowarn:1701,1702,1701,1702,2008 /fullpaths /nostdlib+ /errorreport:prompt /warn:5 /define:TRACE;RELEASE;NET;NET5_0;NETCOREAPP;WINDOWS /errorendlocation /preferreduilang:en-US /highentropyva+ /reference:"C:\Program Files\dotnet\packs\Microsoft.WindowsDesktop.App.Ref\5.0.0\ref\net5.0\Accessibility.dll" /reference:...
2>Metadata file 'C:...\source\repos\WpfApp123-net5\ClassLibrary1\bin\Release\net5.0-windows\ClassLibrary1.dll' could not be found

The "ClassLibrary1.ddl" is not in "net50-windows" folder instead it is in "net5.0" folder.

Currently only amd64 artifacts are published, but we need both architectures.

Not sure if this is the right repo to file this under, but here goes.

Repro steps:

1. Create Windows desktop app, targeting net5.0-windows (or netcoreapp3.1)
2. Create a project reference to a class library, targeting netstandard2.1 (or netstandard2.0)
3. Deploy using ClickOnce, using target framework net5.0-windows, Framework-dependent, Portable

Publish fails, with following build output:

2>Metadata file 'D:\Documents\DeploymentTester\SomeClassLibrary\bin\Release\net5.0-windows\ref\SomeClassLibrary.dll' could not be found
========== Build: 1 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========
========== Publish: 0 succeeded, 1 failed, 0 skipped ==========

If I delete the project reference, or change project reference to target net5.0-windows, publish works fine.
This makes the new ClickOnce unusable for me at the moment, as I have a number of apps with shared libraries that I am attempting to port one at a time, so need to be able to use netstandard2.0 libraries to be compatible with my Framework apps.

When I try to sign with dotnet-mage -Sign Application.application -CertFile /root/file.pfx -Publisher "publisher" in Linux it says

Internal error, please try again. Unable to load shared library 'Kernel32.dll' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: libKernel32.dll: cannot open shared object file: No such file or directory

I found in the source code, that CryptoAPI is only supported in Windows.
Are there any alternatives to get manifests signed without Windows?

I created a MS Word plugin with .net 4.8. The customer has a slightly older version of MS word than what is on my development machine. I get the following error when I try to run the plugin:

System.Security.Cryptography.CryptographicException: SignatureDescription could not be created for the signature algorithm supplied.
at System.Security.Cryptography.Xml.SignedXml.CheckSignedInfo(AsymmetricAlgorithm key)
at System.Security.Cryptography.Xml.SignedXml.CheckSignature(AsymmetricAlgorithm key)
at System.Security.Cryptography.Xml.SignedXml.CheckSignatureReturningKey(AsymmetricAlgorithm& signingKey)
at System.Security.Cryptography.Xml.ManifestSignedXml.VerifyStrongNameSignature(XmlElement signatureNode)
at System.Security.Cryptography.Xml.ManifestSignedXml.VerifySignature(X509RevocationFlag revocationFlag, X509RevocationMode revocationMode) at System.Security.Cryptography.ManifestSignatureInformation.VerifySignature(ActivationContext application, ManifestKinds manifests, X509RevocationFlag revocationFlag, X509RevocationMode revocationMode)
at Microsoft.VisualStudio.Tools.Applications.Deployment.ClickOnceAddInTrustEvaluator.VerifyCertificateSignature(ActivationContext context, OnlineOfflineState offlineState, String productName, DeploymentSignatureInformation& signatureInformation)
at Microsoft.VisualStudio.Tools.Applications.Deployment.ClickOnceAddInDeploymentManager.VerifySecurity(ActivationContext context, Uri manifest, AddInInstallationStatus installState)
at Microsoft.VisualStudio.Tools.Applications.Deployment.ClickOnceAddInDeploymentManager.InstallAddIn()

I tried a test plugin with the .net 4.0 runtime and it worked fine with no issues on my customers computer. What I noticed was that the manifiests were signed with the SHA1 algorithm. So I tried to use mage to re-sign my .net 4.8 deployment manifiest using SHA1 but it only converts part of the manifiest to SHA1. I used the following command:

mage -Update MyApp.exe.manifest -CertHash MyHash -Algorithm sha1RSA

Did I do something incorrectly?

Description

In the initial PR it was pointed out that the use of HttpClient could result in socket exhaustion and that IHttpClientFactory should be used to address this.

The library however only supports .NET Standard 2.0 and .NET 4.6.1, which effectively excludes using it because the releases package targets 4.5.2

The releases.json ProductCollection is referencing the blob storage URL directly instead of using the CDN URL, https://dotnetcli.azureedge.net/dotnet/release-metadata/releases-index.json

Description

Hi guys,
I was reading through your README trying to see how to get started, what process to follow etc, so I naturally clicked on links which may provide further information.

In the section "How can I contribute" the link behind Get Up and Running on .NET Core points to https://github.com/dotnet/deployment-tools/blob/main/documentation/project/dogfooding.md which doesn't seem to exist, as I get a 404

Configuration

N/A

Regression?

N/A

Other information

N/A

Release build legs are failing in main branch:

      "D:\workspace\_work\1\s\artifacts\obj\win-x64.Release\native\INSTALL.vcxproj" (rebuild target) (1) ->
         "D:\workspace\_work\1\s\artifacts\obj\win-x64.Release\native\ALL_BUILD.vcxproj" (default target) (3:2) ->
         "D:\workspace\_work\1\s\artifacts\obj\win-x64.Release\native\projects\NetCoreCheck\EXE\NetCoreCheck.vcxproj" (default target) (5:2) ->
         (Link target) -> 
           LINK : fatal error C1047: The object or library file 'D:\workspace\_work\1\s\.dotnet\packs\Microsoft.NETCore.App.Host.win-x64\5.0.2\runtimes\win-x64\native\libnethost.lib' was created by a different version of the compiler than other objects like 'NetCoreCheck.dir\Release\FileLogger.obj'; rebuild all objects and libraries with the same compiler [D:\workspace\_work\1\s\artifacts\obj\win-x64.Release\native\projects\NetCoreCheck\EXE\NetCoreCheck.vcxproj]
           LINK : fatal error LNK1257: code generation failed [D:\workspace\_work\1\s\artifacts\obj\win-x64.Release\native\projects\NetCoreCheck\EXE\NetCoreCheck.vcxproj]
  
  
         "D:\workspace\_work\1\s\artifacts\obj\win-x64.Release\native\INSTALL.vcxproj" (rebuild target) (1) ->
         "D:\workspace\_work\1\s\artifacts\obj\win-x64.Release\native\ALL_BUILD.vcxproj" (default target) (3:2) ->
         "D:\workspace\_work\1\s\artifacts\obj\win-x64.Release\native\projects\NetCoreCheck\CA\NETCoreCheckCA.vcxproj" (default target) (4:2) ->
           LINK : fatal error C1047: The object or library file 'D:\workspace\_work\1\s\.dotnet\packs\Microsoft.NETCore.App.Host.win-x64\5.0.2\runtimes\win-x64\native\libnethost.lib' was created by a different version of the compiler than other objects like 'NETCoreCheckCA.dir\Release\MsiLogger.obj'; rebuild all objects and libraries with the same compiler [D:\workspace\_work\1\s\artifacts\obj\win-x64.Release\native\projects\NetCoreCheck\CA\NETCoreCheckCA.vcxproj]
           LINK : fatal error LNK1257: code generation failed [D:\workspace\_work\1\s\artifacts\obj\win-x64.Release\native\projects\NetCoreCheck\CA\NETCoreCheckCA.vcxproj]
  
      0 Warning(s)
      4 Error(s)

https://dev.azure.com/dnceng/public/_build/results?buildId=1121249&view=results

cc @MSLukeWest, @NikolaMilosavljevic

This parameter has only one possible value now, and has no effect.

Could you please provide NETCoreCheck usage guide or some other kind of documentation for it?

I downloaded release from NuGet, tried to launch both x86 and x64 NetCoreCheck.exe, but the tool process exits immediately without any output. Passing /?, -? or --help doesn't change a thing.

When .NET ships, we have cases where we only need to process partial JSON files, e.g. a single product release. Although the library supports those, the APIs are all internal and the creation APIs are only available at the ProductCollection level.

We should consider enabling similar Create methods on Product and ProductRelease

With latest Arcade update we now need VS 16.8 for building. All pool machines have also been updated with VS 16.8.

This causes an error in builds of release configuration due to mismatched compiler of new native code and old one, referenced in libnethost.lib.

Error:

2020-12-09T17:42:26.4427684Z        5>LINK : fatal error C1047: The object or library file 'F:\workspace\_work\1\s\src\clickonce\native\Windows\..\..\..\..\.dotnet\packs\Microsoft.NETCore.App.Host.win-x64\5.0.0-preview.6.20264.1\runtimes\win-x64\native\libnethost.lib' was created by a different version of the compiler than other objects like 'NetCoreCheck.dir\Release\FileLogger.obj'; rebuild all objects and libraries with the same compiler [F:\workspace\_work\1\s\artifacts\obj\win-x64.Release\native\projects\NetCoreCheck\EXE\NetCoreCheck.vcxproj]
2020-12-09T17:42:26.4691362Z        5>LINK : fatal error LNK1257: code generation failed [F:\workspace\_work\1\s\artifacts\obj\win-x64.Release\native\projects\NetCoreCheck\EXE\NetCoreCheck.vcxproj]

Once new package has been pushed to nuget.org, documentation should be updated to reflect the change in tool name:
https://github.com/dotnet/deployment-tools/blob/master/Documentation/dotnet-mage/README.md

Right now we build x86 and x64 versions of NETCoreCheck.exe. We should also support building Arm64, and publish a NuGet package for this version as well.

Currently NetCoreCheck could be used to check whether is specific version of runtime is installed.

Would be also convenient to check whether any version within provided range is installed, e.g.: 3.x, 3.1.x, >=3.0.0, >=5.0.0 < 5.1, etc.

#4

Matt's comment:

core-setup-sdl-validation exists and will allow your pipeline to run, but if this repo does Arcade onboarding you should consider having a "TODO"-type issue about using Arcade's SDL validation stuff so you aren't at the mercy of Davis' secrets expiring. (A shared place for secrets to expire makes it more likely to fix itself when things expire / cycle)

We will soon need to run some tests on Linux and need to compile native binaries for those.

Eventually we could have native Linux binaries and packages.

This issue tracks the following work:

• Updates in Azure pipelines for Linux support
• Updates in build infrastructure for Linux support

Objective

Provide ClickOnce Support for .NET Core apps in the .NET 5 timeframe i.e. the ability for .NET Core apps to auto update on launch. This brings functional parity across most of the ClickOnce scenarios for the developer community, particularly those in Enterprise/Line of business.

High level User Experience and Scope

Developer experience includes an updated integrated publish experience in VS with ClickOnce as a new provider option, a new open sourced Mage tool for enabling the command line experience for manifest generation and updated MSBuild tasks to support the changes required in VS and Mage for .NET Core Projects.

At a high level, the proposal is to use a .NET Framework based launcher application, transparent to the user and responsible for activating the .NET Core app specified in the launcher’s config/manifest file. There are no changes expected to the OS components that ClickOnce Runtime relies on, such as Dfshim, DFSVS etc.

Please note that ClickOnce ApplicationDeployment class and its APIs will not be available for use by .NET Core applications. For example, downloading assemblies at will and Custom hosting – InPlaceHostingManager scenarios are not supported. Also, scope does not include support for in-app updates or updates upon app close since the launcher app closes once the .NET Core app is activated. Partial trust is not a supported feature in .NET Core, therefore not in scope.

Windows 7 is not a supported platform. However, Win 7 users with .NET 4.5.2+ will not be blocked from using ClickOnce for deploying .NET Core apps.

I downloaded the nupkgs from the latest build and they fail symchk:

_symchk.exe /s SRV*http://msdl.microsoft.com/download/symbols x86\NetCoreCheck.exe
SYMCHK: NetCoreCheck.exe FAILED - NetCoreCheck.pdb mismatched or not found

SYMCHK: FAILED files = 1
SYMCHK: PASSED + IGNORED files = 0_

This prevents the official build from being used by the VS installer.

Description

We have a filegroup in our clickonce deployment that is optional, contained in the file group are some dll's that are not directly referenced by our project and rarely get updated, they are copied into our projects output folder via a nuget package that just injects content files.

• Downloading the filegroup when needed works great.
• Future runs of that application version also works great, IsFileGroupDownloaded returns true.
• However when we updated our application but did not change any files in the file group IsFileGroupDownloaded returns false and it redownloads them.

The documentation says this:

If a new version of the application has been installed, and the new version has not added, removed, or altered files in the file group, IsFileGroupDownloaded(String) returns true.

However this does not appear to be the case. I did a diff against both version's manifest - the only changes were the application version and the digest of our core application dll (this is what I updated).

Why then, does it say that the file group is not downloaded?

Configuration

.NET Framework 4.6.2
Windows 10 x64
Clickonce application

Regression?

Given that a very similar question was asked before and never answered from 2008 https://social.msdn.microsoft.com/Forums/en-US/910e76ce-d1a2-478c-8f3d-80d736ccb7a6/isfilegroupdownloaded-bug?forum=winformssetup I would make an educated guess that this isn't something new.

When I run dotnet-mage -update Application.application it shows:

Internal error, please try again. The type initializer for 'Microsoft.Win32.Registry' threw an exception.

Version 5.0.301 on Ubuntu 20.4 (x86_64)

Does it refer to Microsoft Launcher (due to capitals) or is it a generic term and, therefore, translatable? Left in English by now, please confirm. Several occurrences, examples: Launcher successfully added. 0; "LauncherSuccessfullyAdded" Launcher template "{0}" does not exist. 0; "MissingLauncherTemplate"

Current: Microsoft.Net.NetCoreCheck

Expected: Microsoft.NET.NETCoreCheck

Launcher can activate FDD (DLL-based) applications by discovering .NET host on user's machine.

Launcher supports default host location (%ProgramFiles%\dotnet and %ProgramFiles(x86)%\dotnet). However, it should also support custom host locations that can be set using environment variables and registry keys.

This feature request is related to FDD only. FDE and SCD applications contain their own apphosts, which are used for app activation.

On March 4th 2021 (Thursday) we renamed the default branch in this repository to main. For more details, see our earlier announcement.

Hi, I have an application that rely on ApplicationDeployment.CurrentDeployment.DataDirectory and ApplicationDeployment.IsNetworkDeployed to be able to get access to a json config file that should be kept between different versions of the same application.
I know System.Deployment.Application is not supported now.
So I'm wondering how I can achieve the same functionality in .NET 5, what is the new strategy with the new tool?

We currently have VS.Redist.Common.NetCoreCheck package that is automatically published to VS feed for every build. As such, VS.* packages have to have unique versioning, and cannot be switched to stable versioning.

New package name ideas:
Microsoft.NET.NETCoreCheck
Microsoft.NETCoreCheck
Microsoft.NET.Tools.NETCoreCheck

Scenario: I publish a .NET 5 app using ClickOnce and then pin the app to the Windows taskbar. After pinning to the taskbar, if I update the app, it will be orphaned to the old version. The Start Menu app icon works fine after the update, it just seems to be the taskbar. Is there any way to work around having to unpin/repin the app icon post update?

Hi,

EV Certs are now given out on a usb stick. I need to make a change to the manifest file for a Clickonce deployment, but mage does not give the option of using the usb stick it only takes .pfx files. Is there some sort of flag I am unware of that will let me resign an app with mage?

.NET (Core) applications deployed with ClickOnce cannot use ApplicationDeployment class for on-demand update check.

Besides checking for new updates, this check can be used to ensure that the deployment is still available on the server and wasn't deleted. If application is doing silent updates, without this check, user won't be aware that application is not getting any updates.

Launcher could do the update check if application is configured to install new updates automatically. We need to find a way to communicate the result of this check to .NET (Core) application. We could potentially also include the result of any recent automatic update.

Hello! I was trying to use dotnet-mage to update the product name (assembly.description.name) of my application in the deployment manifest, but ran into a blocker: updating the product name also changes assemblyIdentity.name to the product name. They need to be different (product name is what's on the Start Menu, etc., while assembly name is a non-user-friendly assembly name), but dotnet-mage appears to have no way to set them separately.

The description of the -Name option says "The name that is used to identify the application. ClickOnce will use this name to identify the application in the Start menu (if the application is configured to install itself) and in Permission Elevation dialog boxes." That seems to imply it should update product name but not assembly name. My understanding of ClickOnce manifests is admittedly lacking so there could be a very good reason they're linked in your tool, though unfortunately in my situation they can't be the same (users would get an error upon startup due to the assembly identity name having changed).

In the meantime I'm simply using sed to update the manifest and then dotnet-mage to sign it, but it would be convenient to be able to do it all through the tool.

Description

Take these two almost identical commands:

dotnet-mage -update <deployment manifest> -AppManifest Application Files/<application manifest>
dotnet-mage -update <deployment manifest> -AppManifest Application Files\<application manifest>

They both work, but produce different codebase values in the deployment manifest:

<dependentAssembly dependencyType="install" codebase="/Application Files/<application manifest>">

<dependentAssembly dependencyType="install" codebase="Application Files\<application manifest>">

The first one is absolute, breaking the download in every situation except if the deployment manifest is in the root folder of the web site. The second one is relative, functioning correctly. The tool should ideally be smart enough to make the path relative regardless of the path separator used.

Configuration

.NET 5, Windows, x64

Regression?

Unknown

Other information

Here's what appears to be the problematic line of code:

Launcher strings and messages are useful for debugging; saved to an optional log file. All strings are in English. Launcher does not have UI and never displays any strings on screen or console.

@joeloff is working on this. The APIs can be reviewed here (internal only link, sorry). The APIs are here:

API Propsal

namespace Microsoft.Deployment.DotNet.Releases {
    public class AspNetCoreReleaseComponent : ReleaseComponent {
        public IReadOnlyCollection<string> AspNetCoreModuleVersions { get; }
        public string VisualStudioVersion { get; }
    }
    public class Cve {
        public Cve();
        public string Id { get; }
        public Uri Url { get; }
        public override bool Equals(object obj);
        public override int GetHashCode();
    }
    public class Product {
        public Product();
        public DateTime? EndOfLifeDate { get; }
        public bool IsSecurityUpdate { get; }
        public DateTime? LatestReleaseDate { get; }
        public ReleaseVersion LatestReleaseVersion { get; }
        public ReleaseVersion LatestRuntimeVersion { get; }
        public ReleaseVersion LatestSdkVersion { get; }
        public string ProductName { get; }
        public string ProductVersion { get; }
        public Uri ReleasesJson { get; }
        public SupportPhase SupportPhase { get; }
        public static Task<ReadOnlyCollection<ProductRelease>> GetReleasesAsync(Uri releasesJsonUrl);
        public Task<ReadOnlyCollection<ProductRelease>> GetReleasesAsync();
        public Task<ReadOnlyCollection<ProductRelease>> GetReleasesAsync(string releasesIndexJsonPath, bool downloadLatest);
        public bool IsOutOfSupport();
    }
    public sealed class ProductCollection : ReadOnlyCollection<Product> {
        public static readonly Uri ReleaseIndexDefaultUrl;
        public static Task<ProductCollection> CreateAsync();
        public static Task<ProductCollection> CreateAsync(string releasesIndexJsonPath, bool downloadLatest);
        public static Task<ProductCollection> CreateAsync(Uri releasesIndexUrl);
        public IEnumerable<SupportPhase> GetSupportPhases();
    }
    public class ProductRelease {
        public AspNetCoreReleaseComponent AspNetCoreRuntime { get; }
        public IReadOnlyCollection<ReleaseComponent> Components { get; }
        public IReadOnlyCollection<Cve> Cves { get; }
        public IReadOnlyCollection<ReleaseFile> Files { get; }
        public bool IsPreview { get; }
        public bool IsSecurityUpdate { get; }
        public DateTime ReleaseDate { get; }
        public Uri ReleaseNotes { get; }
        public RuntimeReleaseComponent Runtime { get; }
        public IEnumerable<ReleaseComponent> Runtimes { get; }
        public IReadOnlyCollection<SdkReleaseComponent> Sdks { get; }
        public ReleaseVersion Version { get; }
        public WindowsDesktopReleaseComponent WindowsDesktopRuntime { get; }
    }
    public abstract class ReleaseComponent {
        public ReleaseVersion DisplayVersion { get; }
        public IReadOnlyCollection<ReleaseFile> Files { get; }
        public string Name { get; protected set; }
        public ProductRelease Release { get; }
        public ReleaseVersion Version { get; }
    }
    public class ReleaseFile {
        public ReleaseFile();
        public string FileName { get; }
        public string Hash { get; }
        public string Name { get; }
        public string Rid { get; }
        public Uri Url { get; }
        public Task DownloadAsync(string fileName);
        public Task DownloadAsync(string fileName, bool verifyHash);
        public override bool Equals(object obj);
        public override int GetHashCode();
    }
    public class ReleaseVersion : IComparable, IComparable<ReleaseVersion>, IEquatable<ReleaseVersion>, ICloneable {
        public ReleaseVersion(string version);
        public ReleaseVersion();
        public static readonly string Version2Pattern;
        public string BuildMetadata { get; set; }
        public int Major { get; set; }
        public int Minor { get; set; }
        public int Patch { get; set; }
        public string Prerelease { get; set; }
        public int SdkFeatureBand { get; }
        public int SdkPatchLevel { get; }
        public static int Compare(ReleaseVersion a, ReleaseVersion b);
        public static bool Equals(ReleaseVersion a, ReleaseVersion b);
        public static bool operator ==(ReleaseVersion a, ReleaseVersion b);
        public static bool operator >(ReleaseVersion a, ReleaseVersion b);
        public static bool operator >=(ReleaseVersion a, ReleaseVersion b);
        public static bool operator !=(ReleaseVersion a, ReleaseVersion b);
        public static bool operator <(ReleaseVersion a, ReleaseVersion b);
        public static bool operator <=(ReleaseVersion a, ReleaseVersion b);
        public object Clone();
        public int ComparePrecedence(ReleaseVersion value);
        public int CompareTo(object value);
        public int CompareTo(ReleaseVersion value);
        public bool Equals(ReleaseVersion obj);
        public bool PrecedenceEquals(ReleaseVersion value);
        public string ToString(int fieldCount);
        public override bool Equals(object obj);
        public override int GetHashCode();
        public override string ToString();
    }
    public class ReleaseVersionConverter : JsonConverter<ReleaseVersion> {
        public ReleaseVersionConverter();
        public override ReleaseVersion ReadJson(JsonReader reader, Type objectType, ReleaseVersion existingValue, bool hasExistingValue, JsonSerializer serializer);
        public override void WriteJson(JsonWriter writer, ReleaseVersion value, JsonSerializer serializer);
    }
    public class RuntimeReleaseComponent : ReleaseComponent {
        public string VisualStudioMacVersion { get; }
        public string VisualStudioVersion { get; }
    }
    public class SdkReleaseComponent : ReleaseComponent {
        public string CSharpVersion { get; }
        public string FSharpVersion { get; }
        public ReleaseVersion RuntimeVersion { get; }
        public string VisualBasicVersion { get; }
        public string VisualStudioMacSupport { get; }
        public string VisualStudioMacVersion { get; }
        public string VisualStudioSupport { get; }
        public string VisualStudioVersion { get; }
    }
    public class SupportPhaseConverter : StringEnumConverter {
        public SupportPhaseConverter();
        public override object ReadJson(JsonReader reader, Type objectType, object existingValue, JsonSerializer serializer);
    }
    public class WindowsDesktopReleaseComponent : ReleaseComponent {
    }
    public enum SupportPhase {
        Unknown = 0,
        [EnumMember]
        EndOfLife = 1,
        Maintenance = 2,
        [EnumMember]
        LongTermSupport = 3,
        Preview = 4,
        RC = 5,
    }
}

Hi,
I'm trying to publish a winforms app (net core 3.1) through the command line. I created a new ClickOnce Profile using Visual Studio (16.8.1), and a click on the publish button was also successful.

I think Visual Studio is using "dotnet publish" in the background. What command line options are used?

When I try "dotnet publish -p:PublishProfile=ClickOnceProfile"
I get the following output:

Microsoft (R) Build Engine version 16.8.0+126527ff1 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  All projects are up-to-date for restore.
C:\Program Files\dotnet\sdk\5.0.100\Microsoft.Common.CurrentVersion.targets(4187,5): error : MSB4803: The task "FormatUrl" is not supported on the .NET Core version of MSBuild. Please use the .NET Framework version of MSBuild. See https://aka.ms/msbuild/MSB4803 for further details. [C:\Users\Marc\source\repos\WindowsFormsApp2\WindowsFormsApp2\WindowsFormsApp2.csproj]

Description

I'm running dotnet mage to publish deployments, but the client is only updating one time. (UpdateOnce ☺️)

I'm expecting the client to always update to the latest required version if there is a newer version available. This is regardless how often new updates are released.

Steps to reproduce:

Prerequisites:

• An empty shared folder with read and write access. (e.g. \\comdev1\clickonce )

1. Create a file deploy-first.bat in c:\temp with content:

set coVersion=1.0.0.0
set appName=TestApp1
set sharedFolder=\\comdev1\clickonce
set providerUrl=%sharedFolder%\%appName%.application

dotnet mage -cc
mkdir c:\temp\%appName%
cd c:\temp\%appName%
dotnet new wpf -f net5.0
dotnet publish -o publish/%coVersion%/
cd publish
dotnet mage -al %appName%.exe -td %coVersion%
dotnet mage -new Application -t %coVersion%\%appName%.manifest -fd %coVersion% -v %coVersion%
dotnet mage -new Deployment -i true -pub "Test Publisher" -v %coVersion% -appm %coVersion%\%appName%.manifest -t %appName%.application -pu %providerUrl%
xcopy *.* %sharedFolder% /S /Y
start %providerUrl%

2. Create a file deploy-next.bat in c:\temp with content:

set coVersion=1.0.0.1
set appName=TestApp1
set sharedFolder=\\comdev1\clickonce
set providerUrl=%sharedFolder%\%appName%.application

cd c:\temp\%appName%
dotnet publish -o publish/%coVersion%/
cd publish
dotnet mage -al %appName%.exe -td %coVersion%
dotnet mage -new Application -t %coVersion%\%appName%.manifest -fd %coVersion% -v %coVersion%
dotnet mage -new Deployment -mv %coVersion% -v %coVersion% -pub "Test Publisher" -appm %coVersion%\%appName%.manifest -t %appName%.application -pu %providerUrl%
xcopy *.* %sharedFolder% /S /Y

3. Run the script deploy-first.bat.
   The script creates a new .NET Core WPF app and publish it. Finally it installs the app on your client.
   Close the started app.

4. Modify the WPF app. E.g. change Title in MainWindow.xaml to MainWindow 1.0.0.1.

5. Run the script deploy-next.bat.
   The script publishes the changed WPF app.

6. Start the app from the start menu. The new version 1.0.0.1 is launched.
   Close the app.

7. Modify the WPF app again. E.g. change Title in MainWindow.xaml to MainWindow 1.0.0.2.

8. Edit script deploy-next.bat. Change first line to set coVersion=1.0.0.2 .

9. Run the script deploy-next.bat.

10. Start the app from the start menu.

Expected result: WPF app is updated and shows title 1.0.0.2.
Actual result: WPF app is no longer updated. Title is still 1.0.0.1

Configuration

• Which version of .NET is the code running on? 5.0.103
• What OS and version, and what distro if applicable? Microsoft Windows [Version 10.0.19042.804]
• What is the architecture (x64, x86, ARM, ARM64)? x64
• Do you know whether it is specific to that configuration? Don't know

Regression?

• Did this work in a previous build or release of .NET Core, or from .NET Framework? If you can try a previous release or build to find out, that can help us narrow down the problem. If you don't know, that's OK. Don't know

Other information

• Do you know of any workarounds?
  If I run \\comdev1\clickonce\TestApp1.application, the application updates to the latest version sucessfully.

Right now the temporary runtime config files created and loaded by NETCoreCheck never have any value specified for the roll forward policy, which limits it's usefulness for determining whether or not a particular .NET app will be able to run. We should add a third parameter to NETCoreCheck for the roll forward policy. For example, running:

NETCoreCheck.exe Microsoft.WindowsDesktop.App 3.1.0 LatestMajor

Should internally create a runtime config file that looks like this:

"runtimeOptions": {
  **"rollForward": "LatestMajor",**
  "framework": {
    "name": "Microsoft.WindowsDesktop.App",
    "version": "3.1.0"
  }
}

An example difference is that if this were run on a machine with just the 5.0.x Windows Desktop runtime the check would now pass.

For more information on roll forward policies see dotnet/docs#12237

Hello guys.

It seems like ApplicationDeployment API won't be ported to .NET 5.0. This API is really important for a couple of important scenarios:

1. it gave us a way to force the user to always use the latest version of the windows forms app
2. it allowed us to easily implement an auto-update procedure for long lived apps (similar to what spotify does)

Without this API, we can no longer implement these scenarios which are crucial for our windows forms apps (installed through clickonce).

I'd like to know if there are any plans to bring the ApplicationDeployment API to .NET 5.0 in future versions or should we simply keep our windows apps forever in .NET 4.8 until it can no longer run in future OS versions.

Thanks.

Description

After migration of a .Net Framework (4.7.2) WPF ClickOnce application to net5.0-windows the original API for file associations seems to be missing and I could not find detailed documentation about file associations in .Net 5.

The definition of the <FileAssociation> can be done with the ClickOnce wizard. ClickOnce will generate a file association element in the manifest file that is registered with windows during setup. That works, windows associates the particular file type with my application, shows the correct icon and starts my new .Net 5 application. However, I can't retrieve the file name of the opened file: Previously, in a .Net Framework app deployed via ClickOnce you would access the clicked file via

string[] activationData = AppDomain.CurrentDomain.SetupInformation.ActivationArguments?.ActivationData;

However, the AppDomainSetup type of net5.0-windows does not have ActivationArguments anymore:

• net48 documentation
• net50 documentation

Alternatives I've tried:

• Environment.GetCommandLineArgs()[1..] but that never worked for ClickOnce apps. You skip index 0, because that is the executable itself. That hasn't changed and the resulting string array is empty. Put differently: associated file double clicks do not translate into command line arguments.
• override the Application.OnStartup(StartupEventArgs e) method and check e.Args. This is empty as well.

Q: how do I programmatically retrieve the clicked filename with .Net 5 onwards?

Configuration

• .Net 5.0.5
• I'm running windows 10 Version 2004 (build 19041.928)
• relevant csproj properties:

    <TargetFramework>net5.0-windows</TargetFramework>
    <PlatformTarget>x64</PlatformTarget>
    <UseWPF>true</UseWPF>

Regression?

Yes, the API was working on .Net Framework (confirmed on 4.7.2).
The API does not even exist on .Net 5.0 or at least not in the same place.

Other information

My publish profile xml looks like this:

<?xml version="1.0" encoding="utf-8"?>
<!--
https://go.microsoft.com/fwlink/?LinkID=208121. 
-->
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <ApplicationRevision>3</ApplicationRevision>
    <ApplicationVersion>2.0.0.*</ApplicationVersion>
    <BootstrapperEnabled>True</BootstrapperEnabled>
    <Configuration>Release</Configuration>
    <CreateWebPageOnPublish>False</CreateWebPageOnPublish>
    <GenerateManifests>True</GenerateManifests>
    <Install>True</Install>
    <InstallFrom>Unc</InstallFrom>
    <InstallUrl>\\... my server URI...</InstallUrl>
    <IsRevisionIncremented>True</IsRevisionIncremented>
    <IsWebBootstrapper>False</IsWebBootstrapper>
    <MapFileExtensions>True</MapFileExtensions>
    <OpenBrowserOnPublish>False</OpenBrowserOnPublish>
    <Platform>Any CPU</Platform>
    <ProductName>my application</ProductName>
    <PublishDir>\\... my server URI...</PublishDir>
    <PublishUrl>\\... my server URI...</PublishUrl>
    <PublisherName>my company</PublisherName>
    <PublishProtocol>ClickOnce</PublishProtocol>
    <PublishReadyToRun>False</PublishReadyToRun>
    <PublishSingleFile>False</PublishSingleFile>
    <RuntimeIdentifier>win-x64</RuntimeIdentifier>
    <SelfContained>False</SelfContained>
    <SignatureAlgorithm>(none)</SignatureAlgorithm>
    <SignManifests>False</SignManifests>
    <SuiteName>my suite</SuiteName>
    <TargetCulture>en</TargetCulture>
    <TargetFramework>net5.0-windows</TargetFramework>
    <UpdateEnabled>True</UpdateEnabled>
    <UpdateMode>Foreground</UpdateMode>
    <UpdateRequired>False</UpdateRequired>
    <WebPageFileName>Publish.htm</WebPageFileName>
    <History>False|2021-04-29T09:00:58.3417469Z;False|2021-04-29T11:00:17.1405860+02:00;False|2021-04-29T10:59:51.1134217+02:00;</History>
  </PropertyGroup>
  <ItemGroup>
    <BootstrapperPackage Include="Microsoft.NetCore.DesktopRuntime.5.0.x64">
      <Install>true</Install>
      <ProductName>.NET Desktop Runtime 5.0.5 (x64)</ProductName>
    </BootstrapperPackage>
  </ItemGroup>
  <ItemGroup>
    <FileAssociation Include=".track">
      <Visible>False</Visible>
      <Description>My description</Description>
      <Progid>My.App.Id</Progid>
      <DefaultIcon>App.ico</DefaultIcon>
    </FileAssociation>
  </ItemGroup>
</Project>

I added WebView2 to my project and deployed through ClickOnce. After installing, I get the following error in Event Viewer:

Description: A .NET application failed.
Application: Case NotePad.exe
Path: C:\Users\brandes\AppData\Local\Apps\2.0\2V7CXATV.M61\CX319N6T.2CJ\case..tion_5964a32ae0c4e4e8_0001.0000_70afaffa3727f90c\Case NotePad.exe
Message: Error:
An assembly specified in the application dependencies manifest (Case NotePad.deps.json) was not found:
package: 'Microsoft.Web.WebView2', version: '1.0.664.37'
path: 'runtimes/win-x64/native/WebView2Loader.dll'

I took a procmon of the launch and it looks like this is the problem:

6:06:25.3103630 PM Case NotePad.exe 24596 CreateFile C:\Users\brandes\AppData\Local\Apps\2.0\2V7CXATV.M61\CX319N6T.2CJ\case..tion_5964a32ae0c4e4e8_0001.0000_71adcf692eb7ed4c\runtimes\win-x64\native\WebView2Loader.dll PATH NOT FOUND Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a "C:\Users\brandes\AppData\Local\Apps\2.0\2V7CXATV.M61\CX319N6T.2CJ\case..tion_5964a32ae0c4e4e8_0001.0000_71adcf692eb7ed4c\Case NotePad.exe"

The path is not created and if I create the following path by adding the folders "\runtimes\win-x64\native":

C:\Users\brandes\AppData\Local\Apps\2.0\2V7CXATV.M61\CX319N6T.2CJ\case..tion_5964a32ae0c4e4e8_0001.0000_71adcf692eb7ed4c\runtimes\win-x64\native\

Then add WebView2Loader.dll, I no longer repro the app failing to launch. Is this expected?

Trying to publish a ClickOnce application with a reference to a class library using an alternate target framework, the referenced framework folder is the same as the main project's framework folder.
For instance, my sample net5.0-windows app adds the reference like so:
/reference:\ClassLibrary1\bin\Release\net5.0-windows\ClassLibrary1.dll
The actual file is in: \ClassLibrary1\bin\Release\netstandard2.1\ClassLibrary1.dll

Sample solution is at https://github.com/rkone/Net5.0ClickOnceReferenceFailure

Mage package (https://www.nuget.org/packages/Microsoft.DotNet.Mage) contains a default package description: "Package description".

This should be updated to be Mage-specific, i.e.: "Mage global tool for building ClickOnce deployments of .NET applications."