Can you specify the platform (x86, x64) of .NET Desktop runtime to be installed?

[mcmap4]

Hi,

We have a .NET 6 Desktop application (net6.0-windows) that has a 32-bit dependency which requires us to target it to x86.

<PlatformTarget>x86</PlatformTarget>

I've successfully integrated DRB with the application project and, once installed, it detects that the .NET 6.0 Desktop runtime is missing, but it downloads/installs the x64 version, not the x86 version. Is there a way to force/suggest/hint that DRB needs to download/install the x86 version? I see in the documentation that you can specify certain versions, but didn't see a way to specify the platform.

Thank you!

[Tyrrrz]

Hi.

Right now there's no way, it takes the bitness from the operating system.

Does the parameter you set in PlatformTarget change anything in .runtimeconfig.json or some other output files?

[mcmap4]

Thanks, I've been looking through the code and was coming to that conclusion.

The .runtimeconfig.json does not show not additional indicators.... that's kind of what I was hoping for though... a "platform" or "targetArch" field for the framework items. Our file looks like this:

{
  "runtimeOptions": {
    "tfm": "net6.0",
    "frameworks": [
      {
        "name": "Microsoft.NETCore.App",
        "version": "6.0.0"
      },
      {
        "name": "Microsoft.WindowsDesktop.App",
        "version": "6.0.0"
      }
    ],
    "configProperties": {
      "System.Reflection.Metadata.MetadataUpdater.IsSupported": false
    }
  }
}

I think I have an idea of how to handle this that I'm going to try... I'll detect presence of PlatformTarget property during build phase and have the BootstrapperTask save it to the config along with TargetFileName and IsPromptRequired. Then it will be available in the AppHost and, if it's set, I can use it to fine-tune which URL is chosen in DotnetRuntimePrerequisite.GetInstallerDownloadUrl() by overriding the use of OperatingSystemEx.ProcessorArchitecture.GetMoniker().

[Tyrrrz]

Yeah, that makes sense. I also wonder if maybe there's something written to the .dll/.exe file itself? If not, then I guess passing a task property is the only choice.

[Tyrrrz]

Also, would you need to install x86 versions of Visual C++ Redistributable in that scenario too?

[mcmap4]

I also noticed comments about using runconfig.template.json... So, I looked into manually adding a config param to the config section which would be available in DotnetRuntime.cs when reading App.runtimeconfig.json. I thought that would be a little less intrusive, but not sure that approach will work... It looks like DRB would need to know that it's a x86 target in 3 places: 1) getting a download URL for the runtime installer, 2) finding local installations from Registry or Program Files [(x86)], and 3) getting a path to the hostfxr.dll in DotnetHost.Load(). 1 & 2 I can get easily through runtimeconfig.json, but getting it for loading hostfxr is not convenient. The Task Properties are available right at the top of the stub app in BootstrapperBase.Run() so I do think that's going to have to be how I do it.

We do not need the Visual C++ redistributable for our situation.

[Tyrrrz]

We do not need the Visual C++ redistributable for our situation.

It would still be nice to test this for a general case. The question is: whether x86 dotnet requires x86 vc++ or if x64 is fine too.