Thank you Ricardo,

I have found if I do not copy the *.deps.json files with the new binaries,
the project works on a Windows machine that has up to 3.1.5 installed. Even
though the development machine has 3.1.6 and supporting SDK installed on it.

Leaving the *.deps.json files in place after the initial install works. The
file was created on the build machine that builds the binaries and packages
all the installers. This machine is currently still on the SDK that supports
3.1.5.

I have now read that page fully multiple times.
The global.json may only be affected by the dotnet new and  dotnet run
commands. Since this is an established project it may not help. This project
shows it was first created with the with the 3.1.3 runtimes. 

At the bottom of that page, it hints on being able to set a lowest runtime
and patch version. (runtime 3.1 and patch 5 == 3.1.5). One needs to put it
in the *.csproj file directly as 
    <RuntimeFrameworkVersion>3.1.5</RuntimeFrameworkVersion>

> For framework-dependent applications, the RuntimeFrameworkVersion
specifies the minimum required runtime framework version.

I will test this at another time.

Tracy



-----Original Message-----
From: ProFox [mailto:profox-boun...@leafe.com] On Behalf Of Ricardo Molina
Sent: Thursday, July 30, 2020 10:45 AM
To: Profox
Subject: Re: [NF] .NET Core build to runtime 3.1.5 with SDK for 3.1.6
installed - Possible?

> 1 - Is there a way to build to a lower release of the runtime?

Create a global.json file and specify the SDK version that you want to use.

https://docs.microsoft.com/en-us/dotnet/core/versions/selection



On Tue, 28 Jul 2020 at 18:11, Tracy Pearson <tr...@powerchurch.com> wrote:

> My searches on the internet are fetching a bunch of build .NET Core 2.1
> with
> .NET Core 3.0 installed.
> I'm in the later stages of getting a product ready for release and the
test
> machines and build machines are still on 3.1.5.
>
> When I want to do a quick build from my system which was installed at
> 3.1.6,
> it refuses to run on the test machines. I get this:
> It was not possible to find any compatible framework version
> The framework 'Microsoft.AspNetCore.App', version '3.1.6' was not found.
>
> I tried dotnet build -f netcoreapp3.1.5 and got this:
> C:\Program
>
>
Files\dotnet\sdk\3.1.302\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Target
> FrameworkInference.targets(127,5): error NETSDK1045: The current .NET SDK
> does not support targeting .NET Core 3.1.5.  Either target .NET Core 3.1
or
> lower, or use a version of the .NET SDK that supports .NET Core 3.1.5.
> [c:\work\pcservice\PcService12\PcService12.csproj]
>
> I distribute software to churches. I don't expect them to have a dedicated
> IT group.
> My concern is what happens when the SDK on the build machine moves from
> 3.1.5 to 3.1.6 due to an update from Microsoft.
> If I have already shipped the product and have it installed on multiple
> system, these systems will need the updated runtimes.
> Microsoft has supplied a PowerShell script that will download and install
> the latest runtime. The problem with that, is the default setting on a new
> Windows 10 Home machine is to not allow scripts to run.
> I know the installer is running as an authenticated administrator. It
> doesn't feel right to change that setting. That just feels like it will
> open
> a security risk on a customer machine. Then can I change it back to what
it
> was? That thought leaves a bad feeling about the whole process.
>
> I have been using INNO Setup for years and was using it with this project.
> 1) I'm familiar with it 2) I ship a COM object and one-click did not
> support
> that when I researched it some years ago.
>
> So here are my questions:
> 1 - Is there a way to build to a lower release of the runtime?
> I know framework-dependent apps roll forward:
>
>
https://docs.microsoft.com/en-us/dotnet/core/versions/selection#framework-de
> pendent-apps-roll-forward
>
<https://docs.microsoft.com/en-us/dotnet/core/versions/selection#framework-d
ependent-apps-roll-forward>
>
> 2 - Is there a different installer available that can help keep the
> runtimes
> updated with the EXE?
> I'm looking at needing to ship an updated runtime each time the build
> machine gets updated.
>
> I considered the Self-contained deployments that include the runtime. This
> would mean when an update to the framework shipped, we should ship a
> maintenance release to address the security problems in the old runtimes.
I
> felt this was a compelling reason to allow Microsoft to update the
runtimes
> and the app could be dependent on the installed framework. Now I have the
> drawback of the build machine has a newer SDK and it builds to that
> runtime.
>
>
> 3 - What have I not thought of going through all this?
>
> Thank you,
> Tracy
>
>
[excessive quoting removed by server]

_______________________________________________
Post Messages to: ProFox@leafe.com
Subscription Maintenance: https://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: https://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: https://leafe.com/archives
This message: 
https://leafe.com/archives/byMID/001401d66692$e1f20000$a5d60000$@powerchurch.com
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Reply via email to