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
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
I'd try posting this into one of Rick Strahl's support forums. I know this isn't connected to WW frameworks but I bet you're going to find a lot more .Net heads there. Maybe even Rick might chime in as he's obviously got a ton of .Net experience, and I know he's blogged quite a bit over the years about handling framework version stuff.
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Tracy Pearson Sent: Tuesday, July 28, 2020 1:11 PM To: profoxtech@leafe.com Subject: [NF] .NET Core build to runtime 3.1.5 with SDK for 3.1.6 installed - Possible?
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
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]
Forums are out of my work flow, and when I've added them to my work flow, they have consumed to much of my time. It's a personal choice not to be part of forums if I can help it.
Want to ask for me? <grin>
Tracy
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Richard Kaye Sent: Tuesday, July 28, 2020 1:58 PM To: profox@leafe.com Subject: RE: [NF] .NET Core build to runtime 3.1.5 with SDK for 3.1.6 installed - Possible?
I'd try posting this into one of Rick Strahl's support forums. I know this isn't connected to WW frameworks but I bet you're going to find a lot more .Net heads there. Maybe even Rick might chime in as he's obviously got a ton of .Net experience, and I know he's blogged quite a bit over the years about handling framework version stuff.
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Tracy Pearson Sent: Tuesday, July 28, 2020 1:11 PM To: profoxtech@leafe.com Subject: [NF] .NET Core build to runtime 3.1.5 with SDK for 3.1.6 installed - Possible?
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
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]
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 tracy@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.
- 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-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]
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-bounces@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 tracy@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.
- 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
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]
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-bounces@leafe.com On Behalf Of Tracy Pearson Sent: Tuesday, July 28, 2020 2:39 PM To: profoxtech@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-bounces@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 tracy@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.
- 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
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/001401d6650e$5e040e80$1a0c2b80$@powerchurch... ** 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.
Report [OT] Abuse: http://leafe.com/reportAbuse/001401d6650e$5e040e80$1a0c2b80$@powerchurch.com
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-bounces@leafe.com On Behalf Of Richard Kaye Sent: Tuesday, July 28, 2020 2:55 PM To: profoxtech@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-bounces@leafe.com On Behalf Of Tracy Pearson Sent: Tuesday, July 28, 2020 2:39 PM To: profoxtech@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-bounces@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 tracy@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.
- 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
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/001401d6650e$5e040e80$1a0c2b80$@powerchurch... ** 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.
Report [OT] Abuse: http://leafe.com/reportAbuse/001401d6650e$5e040e80$1a0c2b80$@powerchurch.com
_______________________________________________ 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/MWHPR1001MB21440ECC4B51DB215446C7FDD2730@MW... ** 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. Report [OT] Abuse: http://leafe.com/reportAbuse/MWHPR1001MB21440ECC4B51DB215446C7FDD2730@MWHPR1...
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-bounces@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-bounces@leafe.com On Behalf Of Richard Kaye Sent: Tuesday, July 28, 2020 2:55 PM To: profoxtech@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-bounces@leafe.com On Behalf Of Tracy Pearson Sent: Tuesday, July 28, 2020 2:39 PM To: profoxtech@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-bounces@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 tracy@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.
- 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
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]
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 tracy@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-bounces@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-bounces@leafe.com On Behalf Of Richard Kaye Sent: Tuesday, July 28, 2020 2:55 PM To: profoxtech@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-bounces@leafe.com On Behalf Of Tracy Pearson Sent: Tuesday, July 28, 2020 2:39 PM To: profoxtech@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-bounces@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 tracy@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.
- 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]
Rofl
Op wo 29 jul. 2020 15:30 schreef Eric Selje Eric@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 tracy@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-bounces@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-bounces@leafe.com On Behalf Of Richard
Kaye
Sent: Tuesday, July 28, 2020 2:55 PM To: profoxtech@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-bounces@leafe.com On Behalf Of Tracy
Pearson
Sent: Tuesday, July 28, 2020 2:39 PM To: profoxtech@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#
-----Original Message----- From: ProFox [mailto:profox-bounces@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 tracy@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.
- 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-de...
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]
Thanks for bringing up old memories. I'm glad I don't suffer from PTSD over those. <smile>
Yet, I still deal with DLL issues. Older versions of the software I maintain has VFP 9 SP1 and a COM DLL. Occasional a customer will get some other VFP product installed. That other product only installs the VFP 9 SP2 HF 3 dlls they need. Meaning, they don't ship the VFP9T.DLL. Suddenly functionality of my program stops working. Since this is done in a separate thread (Thank you Christof for the DMUTL.DLL), no crashing error happens in the program. It happens often enough I wrote a CMD file to search the C: drive for all instances of VFP9*.DLL, display the full path of it and the version. Later I wrote a .NET Framework WPF app that searches the PATH for VFP9*.DLL files, and gives the tech the ability to overwrite the offending problem DLL.
Sometimes it suggests they should delete the file. For those sometimes clever people that think the VFP 9 files are missing and they download RTM and copy them in to the program directory. Oh to have knowledge and not know you don't have enough of the picture to make a good decision. The bane of software design.
I live in both it seems.
Tracy
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Eric Selje Sent: Wednesday, July 29, 2020 9:29 AM To: ProFox Email List Subject: Re: [NF] .NET Core build to runtime 3.1.5 with SDK for 3.1.6 installed - Possible?
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 tracy@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-bounces@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-bounces@leafe.com On Behalf Of Richard Kaye Sent: Tuesday, July 28, 2020 2:55 PM To: profoxtech@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-bounces@leafe.com On Behalf Of Tracy Pearson Sent: Tuesday, July 28, 2020 2:39 PM To: profoxtech@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-bounces@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 tracy@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.
- 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]
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).
For .NET Core 3.x you could try
dotnet publish -r win-x64 -c Release /p:PublishTrimmed=true
Which will build a monolithic EXE with everything unnecessary stripped out.
https://dev.to/mpetrinidev/reduce-the-size-of-your-app-in-net-core-3-and-abo...
This reminds me of the love of simplicity that is my VFP.
:-)
On 7/30/2020 3:46 AM, Alan Bourke wrote:
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).
For .NET Core 3.x you could try
dotnet publish -r win-x64 -c Release /p:PublishTrimmed=true
Which will build a monolithic EXE with everything unnecessary stripped out.
https://dev.to/mpetrinidev/reduce-the-size-of-your-app-in-net-core-3-and-abo...
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 tracy@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.
- 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-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]
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-bounces@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 tracy@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.
- 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
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]
-
Alan Bourke -
Eric Selje -
Jean Laeremans -
MB Software Solutions, LLC -
Ricardo Molina -
Richard Kaye -
Stephen Russell -
Tracy Pearson