Rofl Op wo 29 jul. 2020 15:30 schreef Eric Selje <e...@saltydogllc.com>:
> Isn't it nice to be out of DLL Hell and into .Net Runtime Purgatory? > > > > On Tue, Jul 28, 2020 at 5:01 PM Tracy Pearson <tr...@powerchurch.com> > wrote: > > > Thank you Richard, and Rick. > > > > I will consult with my team on the path we may take in the future. > > > > Tracy > > > > > > -----Original Message----- > > From: ProFox [mailto:profox-boun...@leafe.com] On Behalf Of Richard Kaye > > Sent: Tuesday, July 28, 2020 5:21 PM > > To: profox@leafe.com > > Subject: RE: [NF] .NET Core build to runtime 3.1.5 with SDK for 3.1.6 > > installed - Possible? > > > > As I thought might happen, Rick posted an answer. Here it is: > > > > If you're shipping a vertical application your best bet is to bundle the > > runtimes with the application. .NET Core supports building the > application > > in framework independent mode which includes all the runtime files > required > > to run the application as part of the build output. IOW, you build a > fully > > self-contained application that has no runtime dependencies on a .NET > Core > > Framework. In your case I think this would make sense because the target > > machines are unlikely to have a pre-installed runtime of any kind and it > > side-steps the potential version mismatches. Doing this will make the > > distribution much larger though - a full runtime installation adds > roughly > > 80-90megs to the application (about 30-35megs in an installer package). > > > > The other option is to rely on specific runtime versions being available. > > .NET Core rolls forward to higher point releases, but only up to the next > > point release. (ie. 3.1 and 3.2 are considered different but a 3.11 app > can > > run on 3.15 but a 3.15 app can't run on 3.11). > > > > In the situation with churches it's unlikely that pre-existing versions > of > > .NET Core exist, so distributing self-contained is the way to go I think. > > > > Or if that's all too much hassle - don't use .NET Core but use (full) > .NET > > Framework instead, since that will pre-exist on any Windows machine > Windows > > 7 and forward and just work. This is one of the main reasons why I'm > > sticking with full framework for the time being for any desktop, > non-server > > application development. > > > > +++ Rick --- > > > > -- > > > > rk > > > > -----Original Message----- > > From: ProfoxTech <profoxtech-boun...@leafe.com> On Behalf Of Richard > Kaye > > Sent: Tuesday, July 28, 2020 2:55 PM > > To: profoxt...@leafe.com > > Subject: RE: [NF] .NET Core build to runtime 3.1.5 with SDK for 3.1.6 > > installed - Possible? > > > > I thought about cross-posting it for you, Tracy. I'll act as your agent > in > > this matter for my usual 20% commission. 😉 > > > > -- > > > > rk > > > > -----Original Message----- > > From: ProfoxTech <profoxtech-boun...@leafe.com> On Behalf Of Tracy > Pearson > > Sent: Tuesday, July 28, 2020 2:39 PM > > To: profoxt...@leafe.com > > Subject: RE: [NF] .NET Core build to runtime 3.1.5 with SDK for 3.1.6 > > installed - Possible? > > > > Well, the required version is 3.1.4. Yet it compiled requiring 3.1.6 > > because that is the most recent 3.1.X installed. > > So the downgrade you might be thinking of is going to 3.0 which is no > > longer supported. > > Or 2.1 which doesn't have access to some of the features I'm using in C# > 8. > > > > > > -----Original Message----- > > From: ProFox [mailto:profox-boun...@leafe.com] On Behalf Of Stephen > > Russell > > Sent: Tuesday, July 28, 2020 2:26 PM > > To: ProFox Email List > > Subject: Re: [NF] .NET Core build to runtime 3.1.5 with SDK for 3.1.6 > > installed - Possible? > > > > You can downgrade the version of core required in the project. Either > > way, you have to supply that in your installer. Your clients probably > > won't have it on thier machines. I'd consider using the M$ one because > it > > will bring in the correct bootstraping you'll need. > > > > I only do web installs and not systems that use a forms based UI. > > > > > > > > On Tue, Jul 28, 2020 at 12:11 PM 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 > > < > https://docs.microsoft.com/en-us/dotnet/core/versions/selection#framework-dependent-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/CAPqLOBwYjbny-rAXK-Yu+QT8Bee9Vd33wMno=e3sz28rcqu...@mail.gmail.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.
