I have a WPF application that targets framework v4.0 and uses async BCL. It seems that installing only .net framework v4.0 on fresh W7 OS is not enough, since as it seems, there was a bug which was corrected with later update. For example, installing update v4.0.3 solves the problem with using async BCL on framework v4.0.
My concern is this: On my developer machine (W8.1) I do not have this update installed (at least it is not registered in windows registry, nor under the windows updates). Still, my application is working just fine, which means that the update is somehow installed through some other method.
The question: how can I know that application that uses async BCL will work correctly on client's OS? Currently, when I install the application (wix 3.8), I check if .net 4.0 is installed, and I check if KB2600211 (4.0.3) is installed (by searching adequate registry keys). If not, I install them, but I am wondering if searching for KB2600211 is the right approach? Is there some other way to make sure that app will work correctly?
On your Windows 8.1 you have .NET 4.5.1 which is an in-place update for .NET 4.5 which is an in-place update for .NET 4.0. That means you no longer have plain .NET 4.0 (.NET 4.0.x, for that matter).
I recommend you to always test on the target environments. It can be as simple as having a VM.
Related
Situation
Today there is a security vulnerability in .NET Core 2.1 and we have all of our developers update their .NET Core 2.1.x to .NET Core 2.1.10 but no idea when we'll get around to updating the .NET Core hosting bundles on our production web servers.
Questions
Does the fact that we updated our developer machines become nullified because we haven't updated the web servers yet?
Once our developer's code is pushed to production will those apps run against the older libraries for .NET Core that are on our web servers or will they somehow run in the newer version that our developer machines are building with?
If our projects once pushed to production run under an older version of .NET Core libraries, will we run into compatiblity issues because our developers built against an older version?
I guess my ultimate question is, should we always have a policy in our company to update the hosting bundles on our web servers before we update our development machines?
If you wanna benefit from the update done from .NET Core 2.1.x to .NET Core 2.1.10, I would say : while you don't update the servers, yes.
The apps will try to run under the installed framework on the ervers. If you are publishing using the default mode, your code will depend on the framework installed on your production machines. However, you can change to self contained deployment mode and embed the framework with your code to work on "targeted platform" (https://www.danielcrabtree.com/blog/496/net-core-self-contained-and-framework-dependent-deployments-explained).
It should remain compatible because the versions are both 2.1.x. However I would not try it in production before having tested it in a separated environment.
I believe you should not update your production servers before having tested the new version first. I would change the targeted framework on my development machine, then I would update the framework and the code in (at least) a pre-prod environment. I would test it in this environment. And only then, I would consider a change on the production servers.
Point 3. EDITED based on Daboul comment
I have this issue in which I'm currently targeting .NET Framework 4.7.2 in my solution but the Azure Web App Service only supports up to .NET Framework 4.7.1. So, my question is this: As long as I only use 4.7.1 features, should it work without issue on the Azure Web App Service (which only supports up to 4.7.1) even though I'm targeting 4.7.2? Are the .NET Frameworks backwards compatible? So far, I haven't seen any issues. I just want to make sure there will be no future complications. Ideally, I would like to keep targeting 4.7.2 so that I can start using the 4.7.2 features once it becomes available on Azure Web App Service.
The .NET Framework 4.7.2 builds on previous versions of the .NET Framework 4.x by adding many new fixes and several new features while remaining a very stable product.
The .NET Framework 4.7.2 is included with the Windows 10 April 2018 Update
The .NET Framework 4.7.2 can be used to run applications built for the .NET Framework 4.0 through 4.7.1.
Azure App Service now supports 4.7.2
I think that you did a good thing in upgrading and targeting .NET Framework 4.7.2 ; I also have an Azure App Service and upgraded it to 4.7.2 and it is running very well. As said before, it brings updates and fixes, and it is backward compatible on almost all cases.
Note that the recommended is that the target machine have a .Net version Equal or Greater of the of the .NET Framework 4.x than your compiled version.
See:
https://learn.microsoft.com/en-us/dotnet/framework/whats-new/index#v472
https://learn.microsoft.com/en-us/dotnet/framework/install/on-windows-10
#TheDude, you cannot build an app on 4.7.2 and hope to run it on lower version like 4.7.1. At runtime the target framework version check will fail as it will find the Framework version (4.7.2) as missing.
The other way round (i.e. target 4.7.1 and run on 4.7.2) is fine as the higher versions are backwards compatible.
When I try to run (debug) functions in Visual Studio 2017 on one of our machines, the following dialog pops up!
The target framework for the project is <TargetFramework>net461</TargetFramework>. For some reasons I am not able to install .NET 4.7.1 and now I am completely lost. I am sure it was functioning in the past on the same machine. Probably one of the updates caused it.
Any idea how to resolve it?
This is because the latest version of the Azure Functions Tools for Visual Studio now requires .NET Framework 4.7.1 (as of February 2018).
Note that this does not impact the target framework that you compile against - only the target framework your code runs against. Similarly, when you run in Azure, you can expect the .NET runtime version to be .NET Framework 4.7.1 (at the time of writing).
I tried implementing the solution mentioned in comment. However, it didn't work for me. However, reverting the Azure Functions Tools to previous version worked. Thanks Chris for pointing that it was Azure Tools and not any packages that caused it.
If anyone else should come across this.
For me, the issue was the actual func.exe config that needed to be upgraded.
Navigate to:
C:\Users[USER]\AppData\Local\AzureFunctionsTools\Releases[VERSION]\cli
.. my version was 1.4.0
Modify the func.exe.config to match the .net version installed
.. it was 4.7.1
I am stuck on creating azure batch pool with .net 4.6.1.
I went through those very good resources:
Compute Node - Install .NET 4.6.1
How to get the Windows 2016 Preview OS
and I found out that there is a way to use .net 4.6.1 without installing it manually on a node. There is a programmatic way to set up Windows Ghost image with the latest .net version which is .net 4.6.1 but my node is defined in advance.
I need to have .net 4.6.1 because we use Data Factory and custom activities which are run on azure batch nodes. We upgraded .net version manually on that node but Microsoft doesn't guarantee that the state will preserve and we noticed a few times that node was reset to its original state.
My questions are:
do you know if there is any way on azure portal to choose OS family set to Windows Server 2016 with installed .net 4.6.1 version already?
does anybody know when there will be any os with .net 4.6.1 available?
or should I go with StartTask feature and try to install .net 4.6.1 manually? However, that option sounds like some workaround and not the correct solution.
There is not. They have said that when server 2016 releases on azure, it will be available on batch. Until then, the 4.6.1 install as a startup task is your only option. They also will, at some point, allow us to use custom images, rather than their pre-made images.
Updated 2016-02-07:
You can now deploy OS Family 5 under Cloud Services Configuration in Azure Batch, which is equivalent to Windows Server 2016 (as Marketplace/VM image).
Previous answer:
Answers to your questions:
do you know if there is any way on azure portal to choose OS family set to Windows Server 2016 with installed .net 4.6.1 version already?
Yes, you can change the "Image Type" to Marketplace and select 2016-Datacenter which is Windows Server 2016.
does anybody know when there will be any os with .net 4.6.1 available?
As per above, it's available now for Marketplace (IaaS) under 2016-Datacenter. The Batch team is currently working to support OS Family 5 as a guest OS for Cloud Services.
or should I go with StartTask feature and try to install .net 4.6.1 manually? However, that option sounds like some workaround and not the correct solution.
You can always install it as part of a start task and is considered the proper solution for Azure Batch proper for compute nodes with Windows Server < 2016.
You will still have to use the StartTask to install .NET 4.6.1. In the first resource you mentioned, there's a small piece of code that checks the current .NET installation and installs+reboots if needed.
If possible, downgrade your application's .NET version to 4.5.2 to save the hassle of restarting the node.
I have a C# Windows Forms application that makes use of SQL Server 2008 R2, .NET Framework 4, .NET Framework 4 Client, and Entity Framework Code First.
SQL Server 2008 R2 Express exists on the machine, and the program does create the database and tables.
[Update]
I tried installing .NET framework 4.5, but I got this message:
Blocking Issues:
The .NET Framework 4.5 is not supported on this operating system.
Warnings:
Setup may not run properly, because the Windows Modules Installer
Service is not available on this computer.
with this link
The operating system is Windows XP 2002 SP3 running inside VMware Player.
[Update 25th May 20xx]: I found a link here that caused me to think the problem is just that ClickOnce won't install on Windows XP. However I recreated the set up in Visual Studio 2010 and have the same error.
[update 26 May 20xx]: I created a test project with Visual Studio 2012 and Entity Framework 5 and was able to successfully install on Windows XP using ClickOnce. Strangely I was then able to publish a version of my big application that worked.
I am not sure what is going on. I also did install a program containing Entity Framework 6 on my test computer - but this would not have been referenced by my big application.
Have you tried installing .NET 4.5?
I know it sounds absurd, but we're seeing the same issue: Entity Framework 5.0 (4.4) targetting .NET 4.0, Code First on SQL Server CE.
Installing .NET 4.5 made the issue go away. We're still investigating, because we also have a couple of Windows XP clients.
Update:
Portions of the Entity Framework 5 code are part of the .NET framework itself (that's why there's a 4.4 version for .NET 4.0 that e.g. doesn't support enums, while the 5.0 for 4.5 does).
It seems this issue is related to that since installing .NET 4.5 inexpliccably solves this.
For Entity Framework 6 those portions were moved to Entity Framework, so Entity Framework 6 doesn't depend on framework specifics anymore. We've updated to Entity Framework 6.0 alpha 3 and everything seems fine.
Now, I don't like running alpha code, but this is the only solution we could find.