3 ms·
A perspective from a non-CS engineer. Don't intend to undermine the progress being made. Nevertheless here I am, migrating my dot net core 3.0 application back
by ramshanker 5y ago
A perspective from a non-CS engineer.
Don't intend to undermine the progress being made. Nevertheless here I am, migrating my dot net core 3.0 application back to Dot Net Framework 4.5.1 because I need my applications to run in all those Windows 8.1 (enterprise-internal) PCs without needing admin privileges to install dot net runtime. Since 4.5.1 runtime comes pre-installed with Win 8.1. So that is the version I target for all my new inhouse civil-engineering applications. There isn't much point bloating the application by 80+ MB just to make it self contained executable of dot net core version. After all, I need civil engineering to speedup, not fighting latest framework versions.
- selimthegrim 5y agoHave you considered Blockpad (http://blockpad.net http://blockpad.net) as a platform for your applications?
- fuzzy2 5y agoIf using the self-contained deployment isn't an option then this is the correct solution. I don't see what the problem is. You can't always use the latest and greatest. I often had to use .NET 4.0 because it had to run on some way outdated systems where client IT was refusing to install updates. Bet they got hacked by now, as they should be. ;-)
- runevault 5y agoWhy not use .Net core... 3.1 I think? You can build a standalone exe that doesn't require the runtime on the end user machine. https://docs.microsoft.com/en-us/dotnet/core/deploying/single-file https://docs.microsoft.com/en-us/dotnet/core/deploying/singl...
- gtsteve 5y agoYou might not need to do this. You can roll a fully self-contained distribution that will work for this OS with options to dotnet publish. Unless you're sending your software to Mars, I say that saving 80mb of package bloat is not worth the engineering time especially for an OS that will be EOL in less than 2 years.