Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incompatible when used with .NET 5 in SingleFile option #32

Closed
ngoquoctoandev opened this issue Jul 12, 2021 · 17 comments
Closed

Incompatible when used with .NET 5 in SingleFile option #32

ngoquoctoandev opened this issue Jul 12, 2021 · 17 comments

Comments

@ngoquoctoandev
Copy link

I have a sample WPF project running on .NET 5. Everything works fine for both debug and release environments. However, if I publish the project with target runtime as win-x64 or win-x86 with "Produce Single File" option, the following error occurs.

image

image

This error is logged with Serilog

@MatthewKing
Copy link
Owner

Hello. This is due to PowerShell/MMI#45 - can you target win10-x64 instead? Or one of the other more specific runtimes.

@ngoquoctoandev
Copy link
Author

There doesn't seem to be a suitable alternative. And no specific operating system appears in the target runtime list. Of course, if I choose Portable, there is no "Single File" option.

image

@DaniusLabs
Copy link

same issue when targeting win-x64. Does not even need to be single file.

@ngoquoctoandev
Copy link
Author

same issue when targeting win-x64. Does not even need to be single file.

Confirmed.

@mj2015
Copy link

mj2015 commented Jul 23, 2021

Just to say I too have fallen over this. I don't understand the technicalities, but it looks like a long chain of dependency that would be good to cut out the middle man and go directly to the WMI interface. I'll resort to storing a GUID in a file the \Windows directory until then...

@MatthewKing
Copy link
Owner

This is obviously catching a lot of people out.

For anyone seeing this issue and not wanting to change their runtime identifier, I would recommend just using v5.2.0 for now - it still uses WMI and thus doesn't have any of the issues with the MMI package.

Moving forwards, I think the best option will be to provide both a WMI and a MMI package, so that people can choose which set of tradeoffs they want to make. I'll do this in the next release.

@mj2015
Copy link

mj2015 commented Jul 23, 2021

Ahah! It does indeed work fine with 5.2. Thank you for correcting me.

@MatthewKing
Copy link
Owner

I'm working on a v6 release that will break out the various platform-specific stuff into its own packages. It will allow you to choose between using WMI and MMI on Windows.

For the Windows stuff, you'll have a choice of:

I'm going to go back to recommending the WMI stuff as a default, as the runtime issues with MMI are catching too many users out.

Simple example using the new syntax:

var deviceId = new DeviceIdBuilder()
    .AddMachineName()
    .AddUserName()
    .OnWindows(windows => windows
        .AddProcessorId()
        .AddSystemSerialDriveNumber())
    .OnLinux(linux => linux
        .AddCpuInfo()
        .AddSystemDriveSerialNumber())
    .ToString();

v6 is currently available as an alpha. Alternatively, users who want to stay on v5 can use v5.2.0 for WMI or v5.3.0 for MMI.

@ngoquoctoandev
Copy link
Author

This error is not really fixed even though I am using the latest version of DeviceId 6.2.0

@MatthewKing
Copy link
Owner

MatthewKing commented Mar 2, 2022

It actually is fixed but I can help you out. Are you using WMI or MMI?

@MatthewKing
Copy link
Owner

MatthewKing commented Mar 2, 2022

The following minimal reproduction confirms that it does work as described above:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net6.0</TargetFramework>
    <PublishSingleFile>true</PublishSingleFile>
    <RuntimeIdentifier>win10-x64</RuntimeIdentifier>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="DeviceId.Windows.Mmi" Version="6.2.0" />
  </ItemGroup>

</Project>
using System;
using DeviceId;

var deviceId = new DeviceIdBuilder()
    .AddMachineName()
    .AddUserName()
    .OnWindows(windows => windows
        .AddProcessorId()
        .AddSystemDriveSerialNumber())
    .ToString();

Console.WriteLine(deviceId);

@ngoquoctoandev
Copy link
Author

DeviceId.Windows.Mmi
This error occurs when I publish the application as SingleFile

@ngoquoctoandev
Copy link
Author

My application runs on two operating systems Windows 7/10

@MatthewKing
Copy link
Owner

Please refer to the discussion I mentioned earlier: PowerShell/MMI#45
Or use DeviceId.Windows.Wmi

@MatthewKing
Copy link
Owner

MatthewKing commented Mar 2, 2022

Here is a simple reproduction that confirms you can publish single file on win-x64 using DeviceId.Windows.Wmi:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net6.0</TargetFramework>
    <PublishSingleFile>true</PublishSingleFile>
    <IncludeAllContentForSelfExtract>true</IncludeAllContentForSelfExtract>
    <RuntimeIdentifier>win-x64</RuntimeIdentifier>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="DeviceId.Windows.Wmi" Version="6.2.0" />
  </ItemGroup>

</Project>
using System;
using DeviceId;

var deviceId = new DeviceIdBuilder()
    .AddMachineName()
    .AddUserName()
    .OnWindows(windows => windows
        .AddProcessorId()
        .AddSystemDriveSerialNumber())
    .ToString();

Console.WriteLine(deviceId);

@ngoquoctoandev
Copy link
Author

Why can't be compatible with MMI

@MatthewKing
Copy link
Owner

MatthewKing commented Mar 2, 2022

I've linked to the discussion the MMI repo twice now. Please go read it. Here it is again: PowerShell/MMI#45
You need to include your specific runtime identifiers (example: win7-x64, win10-x64) rather than just using win-x64.
This is just how MMI works. It has nothing to do with the DeviceId library and it's nothing that I can change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants