Unfortunately the organization I work for has a legacy .net application made in XP era, we are in the process of updating but that may not take place until a few months or even the end of the year. This .net app is web based and requires .net framework 3.5, it also needs IE9 or less to run, anything beyond this and the app will break and stop working. Somehow the update for framework 4.5.2 installed, I uninstalled it but for some reason it keep reinstalling by itself over night. I uninstall the update and the next morning I will come into work and it will reinstall. I was reading that the app.config could be set for .net apps to set the parameters of what framework they use. I am not sure where the app.config file would be located for this app or how I could find it for a web based .net app?
For an app named Something.exe, the App.config file (if you need one) should be placed in the same folder and named Something.exe.config.
Related
Is it possible to change from .NET Framework 4.8 to 4.7.2? In my "Turn Windows features on or off", I have ASP.NET 4.8 listed. I wish to change this to 4.7.2 I tried downloading and installing the developer pack from here (https://dotnet.microsoft.com/download/dotnet-framework/net472), but no luck on changing it inside "Windows features on or off".
I don't see any real particular issue by going back on the projects .net version.
The only requirement is that you have the correct version of .net installed on your computer. I suppose you "can" go into windows settings - and if the .net framework is not selected, then fine.
I would NOT suggest that you bother to disable say some given .net framework in the windows settings.
if you need a particular .net framework - then make sure it is installed on your development computer. once done, then in project settings you can select the framework - say like this:
So no, don't disable any .net framework. Sure, you can enable as such, but I would not mess or bother to remove existing frameworks.
About the ONLY real issues are:
If any library or referenced assemblies are LATER then the framework you select, then you can't use such tools, and external libraries.
And of course the target computer then has to have AT LEAST that level of .net installed.
In fact, in some cases, especially some web hosting providers - they are often VERY MUCH behind on what versions of .net are avaible.
And then of course often your have a 4-5 year old production server. They often don't allow updates to such servers to later versions of .net, so you are in your case - can you roll back, or choose a lower .net framework.
I certainly suggest that you adjust, pick, and get your development cycle working on the lowest min target framework. That way you not only avoid (even by accident) using some libraries and tools that can't run on that target web server.
Another FYI? If you select/change that framework in the VS project settings (as per above screen shot), I suggest that after doing so, you exit VS, and re-enter. I experienced some issues when not doing this exit of VS when downgrading the project.
You then want to do a clean project, and then do a re-build all. If that re-build all don't spit out any errors, then you are in rather good shape and should be ok.
Open the Project in Visual Studio >>> Go to Project Tab on Top >>> Select Project Properties >>> Change the Target Frameworkenter image description here from the Dropdown >>> Click Yes to Save the Same
I have ASP.NET Web Application that is deployed on production already. I had to change the target framework of the project from 4.5.2 to 4.7.2 on my local/source and push the changes to developement to get tested.
The problem I am facing is when I changed the target framework of the project the packages did not 'handle' it very well and I had to uninstall and reinstall them with update-package -reinstall -ignoreDependencies
Everything works as normal afterwards but I will need to commit 99+ changes. I am not sure how to handle this migration between the enviroments. So far all of the changes made in the C# code requred only bulding and exchanging the dll file(copying the one from local to development and replacing it) or direct replacement/add to a new javascript/cshtml file.
How I manage to solve the problem is:
After changing the target framework I had to remap the packages as mentioned above which caused a lot of changed in my source. All I did was to build the new 'version' of the project and get the whole bin folder and replace it with the one of the deplyed project in the server side, also I had to compare the changes in the config files.
I started a web project with .net core 2.1 and it works just fine.
But now a vendor says his server side component only works with .net 4.6.1
Can I now change the target framework on the project to 4.6.1 without rewriting the app?
The component helps export data to PDF and Excel, and uses many of the Standard Libraries. So I am at a loss on how to integrate this.
One idea is to create a separate API server that is on 4.6.1, for just the data export but the issue with that is security - the end user is logged into Server A, not Server B, so there are now security issues to deal with.
Maybe calling server B directly from Server A would be possible so I know the person is logged in, then returning the result back to the end user from Server A.
NOTE:Edit to 4.6.1 from 4.7.2 in the above in case that makes any difference.
Yes you can. Simply follow this here
Pulling code from the Stackoverflow link, you simply modify the .csproj file to suit your needs to the .NET Standard lib you're targeting.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard1.6</TargetFramework>
</PropertyGroup>
</Project>
By judging from the documentation provided by Microsoft and by a 3rd party service, you're advised to target .NET Standard for your .NET Core project in order to maximize compatibility with your vendor first. From there, you may most likely one to deploy a second server that completely targets .NET Core to roll out functions with modern APIs.
Take note that .NET Core 2.1 targets 4.6.1 onwards meaning that you will be writing a project that is unable to support anything older than that.
I want to note that the easiest way to run .netcore on the full .netframework is to start with such a project.
You can select .netcore/.net framework when you create the project. This will select all the correct libs for you to get started. Switching midstream can be done, but it takes fiddling with the libs to get the correct versions.
In previous versions of what is now .NET Core, using the dnx toolchain, it was possible to run an application straight from source code, without compiling to a DLL on disk. This capability was also present on Azure, allowing you to edit code on the server and have those changes reflected in the live site.
The new dotnet CLI run command seems to automatically create the familiar bin and obj folders with compiled DLLs in them, and the publish process from Visual Studio to Azure now no longer includes the C# source, just the DLL.
Is it no longer possible with the new CLI and other tools to run .NET Core code without creating a DLL on disk?
Short David Fowler response:
Dynamic compilation is gone in RC2. It only exists for views now. There are no plans to bring it back.
Why?
Architectural challenges and changes require to implement it on both .NET Framework and .NET Core. We did it with dnx and there were some problems (like some things being completely broken with in memory assemblies) that we chose to just avoid.
I have a Vs2008 project using version2 of the ASP MVC framework. I tried to upgrade to VS2010. I fetched a new copy from svn and opened it. I got the expected conversion dialog, clicked next and then finish. A while later comes up a question do I want to also upgrade to the version 4 of .net framework.
I've done this same process twice wioth the same project. THe first time I clicked no and the second time I clicked yes. But, if i run a diff across the directories created, there's essentially no difference (some generated dlls differ and there's a path difference in the vbproj file but that's it). If, however, i diff the new and old project I get a whole load of differences. That's of course expected, but some of them seem to indicate that it's done the upgrade to .net4 anyway! For example, the vbproj file now referneces 4 instead of 3.5 as it's tools version and all the reference.vb files generated from the .wsdl files for my web references now have "Runtime Version:4.0.30319.1" instead of "Version:2.0.50727.4927" and Resources.Designer has a similar.
So, my question, should there be a difference between the version where I said "yes, upgrade the -net framework to version 4 for this project" and the version where I said no or does ASP run with the old version anyway? I really don't want to find that my new version doesn't work when deployed to production servers which may not have .net 4 installed!
You can always change it back to 3.5 in the project settings, so long as you don't upgrade the MVC version to MVC3. Some of those settings may say 4.0 because they depend on the VS2010 designer, which is based on 4.0, and thus needs to reference 4.0 versions at design-time.