I don't have access to an IIS server but I am told that the site is configured to run with version 1.1 of the .NET Framework. When I use Telerik JustDecompile I see the following.
The "NET 1" seems to suggest that the 2 dlls are compiled against version 1.1 of the FW. Does the "ANY" next to the website dll "GLSS" indicate that the site can run against any version ofthe .NET FW that is installed on the web server?
In preparation for an upgrade to 2.0, I have asked the web admins to change the site configuration to version 2.0 of the FW and I was surprised that the site, which I considered to be running 1.1 code, still worked. Should I be surprised?
Is this just a simple example of backward compatability and that the site could be configured to use any version of the framework provided that it was equal to or higher than the version that the code was compiled to use?
when I look at the property pages for the projects in the solution, I was surprised that, for the website project only, I was unable to locate where one sets the version of the FW which you want to compile against. I was able to locate it for the referenced projects.
Can you help me better understand the relationship between the version of teh FW that a site is configured and the versions that the assemblies are compiled against?
You should not be surprised, .NET was always backward compatible in a sense that assemblies compiled against a version of the runtime are supposed to run against a newer version of the runtime.
There are of course subtle issues where things are not backward compatible, starting from subtle semantic differences and ending with changes at the object contract level (where the expected method/class just does not exists anymore) but in general these problems depend on the complexity of your application. It is safe to assume that simple applications should just work with no issues.
The number of the runtime the assembly has been complied against is a part of the assembly's metadata, it can be read with reflection. Thus, at runtime, you have at least two possible versions of the runtime - the one the assembly has been compiled against and the current version of the runtime which executes your code.
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
Issue:
I'm referencing the IConfiguration interface in a .net core 2.1 library that will run in a linux docker container
Visual Studio 2019 automatically offers to add an assembly reference for me. If I accept, it references the Microsoft.Extensions.Configuration.Abstractions.dll that is in my program files directory.
However, I see that there is also a nuget packager for this dll online.
It's easy to say "just trust visual studio", but I've run into issues before with the .net framework where VS (or resharper) will try to add an assembly reference when the assembly it wants to reference is really part of a package that needs to be added.
I'm a long-timer with .net, just picking up .net core. What's the correct convention in this case?
.NET Core is designed with package references as standard way to reference dependencies. There are several reasons for that design choice, however, the primary one is to allow to run code on multiple OS and arch targets. Therefore, recommended way of creating dependencies is by using package references. It will allow to fetch packages which are relevant for given OS and CPU combination.
For example, you could target with you build Windows, Linux and macOS and for Linux and Windows x64 and arm64 architectures while for macOS x64 architecture. Project referencing packages will pick for a given combination of operating system and processor architecture appropriate packages i.e. in case of SQLite it would be win-x64, win-arm64, linux-x64, linux-arm64, macOS-x64 package versions. The same is true for .NET Core packages and runtimes which would be chosen based on combination of target platform and target architecture. The general concept of handling all these combinations is abstracted by Target Framework Moniker which besides of handling OS and architecture information allows to handle version dependency information as well.
All the above is a fundamental concept for understanding versioning and OS/architecture dependency handling in .NET Core which is implemented in it's project system as well. In the case as yours you should always choose nuget package instead of assembly reference, despite suggestion made by Visual Studio which in general not always works correctly. To verify this one can check number of issues which were closed or are still open in dotent/project-system repository on github where .NET Core project system used by Visual Studio lives.
Finally, despite that referencing pure IL assemblies will work it is not future proof, since any change in the dependency which makes it platform or architecture specific (i.e. architecture specific optimizations with .NET Core HW intrinsic) would break your project.
I'm trying to add a full framework class library as a project reference to asp.net core 2.0 MVC project and getting the below error.
Project XYZ is not compatible with netcoreapp2.0 (.NETCoreApp,Version=v2.0).
Project XYZ supports: net462 (.NETFramework,Version=v4.6.2)
I have updated to the most recent version of Visual studio i.e, 15.3.5.
Is it even possible to reference 4.6.2 libraries in core 2.0 projects?
The first thing that you can try is to compile the library you want to consume as netstandard2.0.
Theoretically (according to the .net standard documentation), this will make it compatible with projects using net461 and later as well as netcoreapp2.0 and later.
In practice, sometimes you will end up with a problem with one of your dependencies that don't provide the same library version across different compilation targets.
In such cases you may simply need to add the .net core 2.0 as a target framework for the XYZ library.
The xml tag listing the targets is <TargetFrameworks> in the XYZ.csproj file and is not handled by the Gui of the project's properties.
So I would give a try at editing the XYZ.csproj by hand and add or replace what's listed as <TargetFrameworks> with netcoreapp2.0.
If you are adding it as additional target you need to separate them with ';' as in
<TargetFrameworks>net462;netstandard2.0;netcoreapp2.0</TargetFrameworks>
More details about this in this Microsoft doc.
Please keep in mind that this will trigger multiple compilations and will slow your build consequently...
It should be. Microsoft announced a ".NET Framework Compatibility Mode" with the release of .NET Standard 2.0. However, they didn't go into great detail about how it works exactly, or what to troubleshoot if it doesn't. Additionally, they only specific talk about it in relationship to Nuget packages, so it's possible there's some role Nuget is playing in the process, as well. Unfortunately, I've been unable to find any additional information about this feature outside of the announcement post.
That said, Microsoft's explicit recommendation is to not rely on the fact that your .NET Framework library may just happen to work in .NET Core; instead, you should be actively porting .NET Framework libraries you control to .NET Standard. I'd say you're likely going to spend more time trying to figure out why it doesn't "just work" than you would porting your code, so that it will definitely work, and be future-proof to boot.
The following solution worked for me.
Deleted bin and obj folders from all the projects in the solution, rebuild and if it still doesn't work try changing browser from debug options. for eg. If you already have chrome as default browser in Visual studio, switch to Edge or Firefox.
I've created a new ASP.NET 5 project and I faced with something that I didn't understand well about how the new ASP.NET works.
In my references there are DNX 4.5.1 and DNX Core 5.0. When I install a new package from Nu-Get, some packages install successfully in both and some tell me they aren't supported by DNX Core 5.0.
Can I use many versions of DNX for supporting my packages or I must bound the things with DNX Core 5.0 to enjoy the advantages of ASP.NET 5, like cross-platform and others?
ASP.NET 5 projects are multi-targeted, which means you can compile for multiple platforms simultaneously. In your case .NET 4.5.1 targets ASP.NET 5 on the full .NET runtime (4.5.1) and .NET Core (5.0). When you compile your project, ASP.NET 5 actually creates output for both of these targets so - assuming you get the code to compile for both platforms - the application can run on either of them. It's possible to run additional targets to your projects.
When you actually run your application though, you have to pick a specific version of the .NET runtime you want to run under. In Visual Studio there's a drop down in the project settings where you can select that runtime that actually executes. When you use command line publish you also specify which platform to publish to with a parameter (if omitted it uses the active DNX runtime I believe).
As to the differences - .NET Core is a trimmed down version of the full .NET runtime, that is cross-platform and can run on Windows and other platforms like Linux and OSX. Because it has to run on other platforms a lot of the platform specific Windows features are not supported in this runtime, and as the platform is still evolving some APIs are simply not implemented yet in .NET Core. This is the reason you are likely to see many compile errors when you target .NET Core with existing code/libraries. In order to run on .NET core existing .NET code typically needs at least some minor adjustments to account for the smaller API footprint and potentially serious redesign to work around missing functionality.
If you need to use existing code and depend on assemblies/NuGet packages that are based on previous versions of .NET you have to stick with the full .NET version. You can still take advantage of the new ASP.NET 5 features and eco-system, as well as getting the benefit of the full .NET runtime and full API surface you are used to from previous .NET versions. The downside is that the runtime is Windows only and has a bigger resource footprint.
.NET Core is a new runtime and you should treat it as such. Migrating to this platform is likely not a trivial task. The benefits of this platform is a much leaner footprint and that it can run across multiple OS platforms.
It's likely that it'll take some time for the full potential of .NET Core to come to fruition as Microsoft expands the feature set and cross-platform compatibility but we won't really know what this will look like since it is still in Beta (well RC but it's really a beta with major changes still coming in RC2).
We have recently taken on support of a web application that was written many years ago and targeted v1.1 of the .net framework. It runs on Windows Server 2003/IIS 6 environment.
After looking at the configuration of the site in IIS the target framework is set to 2.0.
Given that extended support for .net 1.1 will cease in October of this year (http://support.microsoft.com/lifecycle/?p1=1249) I am trying to ascertain whether the site will still use any of the .net 1.1 framework assemblies given that the application is built and compiled in Visual Studio 2003.
I am assuming this is the case because although ASP.net 2 is set as the target framework
in IIS (and therefore the aspet_isapi.dll invoked is the .net 2 one etc) the assembly is a .net 1.1 assembly and will therefore still use the 1.1 framework. However, is this assumption actually true?
The website only has another year or so to live before being replaced by a new solution entirely so I would prefer not to upgrade it if possible and run the risks such changes bring with them.
However, we obviously can't run something on an unsupported version of the framework if any element of if that framework is actually being used.
Any thoughts would be appreciated.
Update:
It would seem that .net 1.1 is a core component of WS2k3 so you can't just uninstall it. I could have attempted to remove the ASP.net component but I don't think that would fully uninstall everything and given that the dev environment is shared I can't risk causing any issues right now.
However I have previously set everything up on my local machine (Windows 7/IIS 7), so I changed the application pool to point at .net 2 (it was already running in classic pipeline mode), uninstalled .net frameworks 1 and 1.1 and cleaned up the files left behind afterwards.
The result was that the site ran absolutely fine, which would suggest in an IIS 7 environment at least that I don't need to worry about upgrading given we are running under .net 2 within IIS.
It's not an ideal test as it isn't a mimick of our live environment. I'm going to post a question on MSDN and asp.net to see if any Microsoft folks can add anything more definitive. I will post back here with any updates.
Just because official support will end doesn't mean Microsoft will pull the plug and force an uninstall of .NET 1.1 via Windows Update. It only means that:
if a gaping hole in the framework's security is ever found, they'll not fix it;
There won't be redistributables for the next versions of Windows, and the next version of IIS won't run it.
So the application will still run in a year. If you leave the server alone, the application might run until the machine breaks of old age.
So my suggestion is relax, and focus more on the new solution.
I got the answer to this questions after reading this link (provided as an answer to this question on the ASP.net forums)
http://msdn.microsoft.com/en-us/library/ms994381.aspx
Under "Application Load Mechanisms and Possible Issues" it states:
By default, an application built using the .NET Framework will run using the version of the Framework it was built against if that version is installed on the computer
It then goes on to detail (for .net 1.1 and 2.0 at least) when a particular version of the framework is used.
Essentially, because our server has both 1.1 and 2.0 installed the application will still be using version 1.1. If 1.1 was not installed then it would run by default under 2.0, which explains why the web application still worked after I uninstalled .net 1.0 and 1.1 from my local machine.
Given that the live server is W2K3 and I can't remove .net 1.1, I will be rebuilding my application to target .net 4.0.