I have an ASP.NET MVC application created with Visual Studio 2017. I've been trying to use the AllowXRequestsEveryXSecondsAttribute for a controller action, but I can't find the assembly and namespace where it is defined. Apparently, the attribute's class is not defined in .NET Core yet, but I'm using .NET Framework.
Does anybody know the assembly and namespace where the attribute's class is defined?
The AllowXRequestsEveryXSecondsAttribute is not part of .NET Framework nor .NET Core. It is actually comes from 3rd party outside Microsoft, particularly to showcase security best practices in .NET Framework.
Microsoft has clarified this in their ASP.NET Core github:
https://github.com/aspnet/AspNetCore/issues/6836
The library itself is in the form of project template, and it is only for .NET Framework mainly for .NET Framework 4.6.1 or later. Therefore it is not advisable to use this for your .NET Core project.
FYI, this is the link of the github repo that contains the implementation, usage and sample is at:
https://github.com/johnstaveley/SecurityEssentials
Related
I'm still getting to grips with .Net Standard vs .Net Core after many years of development ASP.NET Framework. I have set up a new Web Api "app" which targets netcoreapp3.1 framework along with a middle-tier/Business Logic ClassLib and Data Access ClassLib, both of which target .Net Standard for maximum future compatibility. However, I can't seem to use ISystemClock from the Microsoft.AspNetCore.Authentication namespace in the .Net Standard classlibs!
From reading this SO question, I believe this might be because netstandard2.0 might not implement Microsoft.AspNetCore.App framework. Is this correct?
If it doesn't, should I:
Provide my own IMySystemClock interface in my class libraries which
the "app" itself can implement a trivial concrete class for?; or
Change my class middle and data access tiers to netcoreapp3.1
framework (seems over kill and restrictive to do this)?
Something else? Maybe I am missing the point of .Net Standard`?
A service (like ISystemClock) to provide the current (real or mock) time seems quite a fundamental service so I'm unsure why it's not appearing in .net standard framework?
Thanks
BloodBaz
If you want to access that functionality from a library, change the target framework of your library to .NET Core 3.1. Libraries can be built in .NET Standard or .NET Core. You can't use .NET Core functionality within a .NET Standard library, but you can do the reverse. Use .NET Standard functionality within a .NET Core library.
Also as a side note, unless it's required for compatibility reasons, I recommend you switch to .NET Standard 2.1. Visual Studio defaults new projects to .NET Standard 2.0, but a ton of new functionality was added in .NET Standard 2.1.
I spent years in the .NET Framework, so I feel the confusion. It took me a while to get used to it. I have a huge project I recently migrated over from .NET Framework to .NET Standard / .NET Core. What I ended up doing was dividing my code up into three sections. A .NET Standard 2.1 library with all the non .NET Core specific common code, a .NET Core 3.1 library with all my .NET Core specific common code (which referenced my .NET Standard library), and my applications as .NET Core 3.1 projects (which referenced my .NET Core 3.1 library).
Make sure you take a read at the answer in this question as well: What is the difference between .NET Core and .NET Standard Class Library project types?
I'd really like to start using .NET Core and slowly migrate applications and libraries to it. However, I can't realistically upgrade my entire code base to use .NET Core and then go through the process of testing and deploying a plethora of applications in production.
As an example, if I create a new .NET Core application and try to reference one of my .NET Framework projects I get the following:
The following projects are not supported as references: -
Foobar.NetFramework has target frameworks that are incompatible with
targets in current project Foobar.NetCore.
Foobar.NetCore: .NETCoreApp,Version=v1.0
Foobar.NetFramework: .NETFramework,Version=v4.5
Is it possible to create a new .NET Core application and reference my existing .NET Framework libraries? If so, what's the process for doing that? I've spent hours going through Microsoft's documentation and searching their issues on GitHub, but I can't find anything official on how to achieve this or what their long-term vision is for this process.
Old question, but with the release of .NetStandard 2.0 and .netcore 2.0 and vs2017.3, the game has changed.
You can use the Full .NET Framework (TFM) with .NetCore 2.0, but how?
In Visual Studio 2017.3, you can reference the Full .NET Framework (any version) directly from within a .NetCore2 project.
You can build the .NetStandard2 class library and reference your TFM. Then reference your .NetStandard2 library from your .NetCore2 project.
For example, referencing json.net net45 from .NetStandard2.
Browse to the folder and select version net45 (not netstandard1.3)
See the dependency in the image below, no yellow warning as you see.
Even if a Nuget library is not ready to be ported to .Netstandard 2, you can use any API in the library that is compliant to net461.
Quoting for the .NET Core 2/Standard 2.0 announcement with links:
.NET Core 2.0 is able to freely reference libraries that have been built for .NET Framework up to version 4.6.1
However, some libraries may fail at run time if they try to use API methods that aren't available on .NET Core
Reference: .NET Core App target .NET framework 4.5.2 on Linux
A need to use third-party .NET libraries or NuGet packages not available for .NET Core
So only in cases where the libraries or NuGet packages use technologies that aren't available in .NET Standard/.NET Core, you need to use the .NET Framework.
Reference: Choosing between .NET Core and .NET Framework for server apps
You can now reference .NET Framework libraries from .NET Standard libraries using Visual Studio 2017 15.3. This feature helps you migrate .NET Framework code to .NET Standard or .NET Core over time (start with binaries and then move to source). It is also useful in the case that the source code is no longer accessible or is lost for a .NET Framework library, enabling it to be still be used in new scenarios.
Reference: Announcing .NET Core 2.0
Yes, we are currently attempting the same thing. The trick is to make sure that you are supporting the same .NET frameworks. Inside your project.json file, make sure the framework matches the framework of the project you wish to include. For example:
"frameworks": {
"net46": { --This line here <<<<
"dependencies": {
"DomainModel": {
"target": "project"
},
"Models": {
"target": "project"
}
}
}
},
FYI: You might need to change the framework of your .NET Core or your older projects to achieve this. .NET Core can be changed just by editing the project.json file as seen above. You can so the same in .NET projects by right clicking the project and opening properties. Change the framework level there.
Once you have matched the two project frameworks then you should be able to include them. Good Luck!
We delayed migrations as long as could as it seemed daunting as first. But we got an insistent client who wanted to migrate ASAP.
So we migrated their Fintech Web App developed on .NET Framework 4.8 Web Forms to .NET 6 Razor Page. Our team scoured though hundreds of online resources & spoke to Microsoft Tech Support before we started the project. Hope the high-level walkthrough of our journey help you plan your migrations.
Our .NET Framework Website consisted of 1 .NET Web Forms project and 12 Class Libraries.
Here is how we did it.
Refactored the .NET Framework 4.8 Web Forms code
We ensured that the Web Forms code behind did not have a single line of service or business logic code. When we did find some business logic code in the web forms code behind, we refactored it, by moving it to the class libraries.
Created new .NET Standard projects
We created a new .Standard 2.0 Class library project for every .NET Framework 4.8 Class Library. If the original project was called "FintechProjectName.StockMarketClient", we named the .NET standard project "FintechProjectName.StockMarketClient.Standard".
Copied all files from .NET framework to .NET standard
We copied all the class files from .NET framework to .NET standard projects. We then removed all the .NET framework class libraries from the solution and added references to the new class libraries. All projects compiled on the 1st try itself and all our test cases too passed with minor changes.
Create new .NET 6 Web App Project
We created a new .NET 6 Web App Project. We had to entirely redo the front-end as there is no direct path for migrating Web Forms to Razor Pages. This was the only project which took us about 1 month to migrate.
Reference .NET standard class libraries in the new .NET 6 website
We copied all the .NET Standard libraries to this new solution containing the Razor Pages web site. Added the references and got it to work.
Move from .NET Standard to .NET 6 class libraries
Once the new website was up and running, with all test cases passed, we did the last step in the process which was the simplest. Created .NET 6 class library projects for each of the .NET standard libraries and named the projects appropriately. Copied all class files from .NET standard projects to their corresponding .NET 6 projects. Then we removed the .NET Standard libraries and added references to the new class libraries.
Overall project timelines were about a month and a half, most of it spend on Razor Pages implementation using the same html design.
Note:
If you are using any 3rd party library which does not have a .NET standard or .NET 5 version, then you are out of luck. You will need to find a replacement nuget package and recode your application to use this new library.
In my case with .net6 referencing framework 4.8 library ( both winforms), the trick seems to be to add the reference to the framework dll as a shared reference.
What is the difference between System.Web.Mvc's FileStreamResult and Microsoft.AspNetCore.Mvc's FileStreamResult? Is there any significant take away of using the latter over the first one?
Edit:
Is it possible to have .Net Core project but still use System.Web.Mvc? I don't know how but just asking for possibility here, is it or is not?
The System.Web.Mvc namespace is used the .NET Framework. If your project is targetting the .NET Framework, use this.
The Microsoft.AspNetCore.Mvc namespace is used in .NET Core. If your project is targetting .NET Core, use this.
Only one of them will be available to you, depending on your project.
You can have an ASP.NET Core project that targets the full .NET Framework, and then add a reference to System.Web.Mvc.dll directly. That might work. But I don't know why you would want to.
But if your ASP.NET Core project is targetting .NET Core, then there is no way to use System.Web.Mvc.
System.Web.Mvc namespace is used by the .NET Framework MVC. Microsoft.AspNetCore.Mvc is used by .NET Core MVC. Pick appropriatly for the type of project you are building.
I have a class library using .Net Framework 4.5, in the code I'm using HttpWebRequest of System.Net.
If I use in a console application using .Net Framework 4.5, it's ok.
If I use in a console application using .Net Core 2.2, it's ok but it's using System.net from .Net Core 2.2 and not from .Net Framework 4.5.
There's a bug/correction in .Net Core 2.2 HttpWebRequest and I want to use the .Net Framework 4.5 version but my application is in .Net Core 2.2.
Is this possible?
Nope. It's best to think of the target framework for a class library as simply an interface. It's dictating a certain API footprint, but the actual framework code is not bundled into the class library.
The actual framework dependencies are satisfied by the end application that utilizes the class library. As long as there's an acceptable level of API compatibility, then you can add the reference, but when it comes time to compile, the target framework will be that of the application itself, not the class library.
If you absolutely need the .NET Framework version, then your only choice is to make your console application target .NET Framework as well, instead of .NET Core. You can still use the new project format; you just won't benefit from cross-platform or things like being able to deploy self-contained.
I have a .NET Core (ASP.NET Core) project created using Visual Studio 2017 RC (MSBuild).
I also have an old F# project library (traditional .NET Framework Library) that compiles to a dll file. I want to use it in said ASP.NET Core project.
To do that, I added a project reference in the ASP.NET Core project, opened the namespace, and made a few function calls in my controllers; it works perfectly when running the ASP.NET Core server using ISS from VS.
My question is, will this arrangement work if I want to deploy to linux (Ubuntu)? Or does using external PCLs/dlls from .NET Core instantly make it windows-only?
Note that I didn't have to add .NET Framework as a target framework in my csproj (it's MSBuild Core), it just worked.
Since your F# project targets the .NET Framework it will not run cross platform. If you modify your F# project to target the .NET Standard library it will. Here is a video by Immo Landwerth explaining how the .NET Standard Library works.
You should be able to just to reference the .NET standard library and not have to change anything. However the current version, which is 1.6, is missing a lot of API's from .NET Framework. This is fixed in 2.0. Infact since your using .NET Core 1.1 I think you are already using 2.0, but I'm not certain. Here is another video by Immo explaining how it should work.
That being said, I'm not sure what the F# support is like with .NET Standard.