We have a large Class Library that uses EF6, which is now upgraded to EF6.3 so it can be used with .net Core 3. I want to use that library in a Blazor Server Side App. The problem is, I can't seem to register the connection string. In blazor I am supposed to put the connectionstrings in appsettings.json which I have done, but I can't register it because the normal way to do that (as far as I understand. I am not familiar very familar with blazor, mvc or .net core) is calling the following function inside the ConfigureServices method of the Startup.cs class:
services.AddDbContext<MyDbContext>()
That method is an extension method form the efcore framework which I am not using. What to do if I use EF6.3(4) for core?
I have a WebForms project and there I web.config
As I suspected, it was a dumb question. The problem was the Edmx file, which I linked from a .netframework project. I did that because I need the classes and the edmx file. I used this tutorial for that: https://github.com/aspnet/EntityFramework.Docs/issues/1748.
In order to get it to work I just needed to add an app.config file to the Blazor project and add the connectionstring which is used for the Edmx file.
The services.AddDbContext() was not needed at all.
Related
I am trying to do an online library(as in an online book store) using ASP.NET MVC. I can't find the Program.cs file or the Startup.cs file.
I tried manually creating the Program.cs file but when I write the line
var builder = WebApplication.CreateBuilder(args);
it does not find the WebApplication class.
I tried adding
using Microsoft.Graph;
but then I get another error:
WebApplication' does not contain a definition for 'CreateBuilder
What should I do?
Serge made a good point in the comments. Based on your notes, it looks like you have created a .NET 4 project. What you want to do is recreate your project as an ASP.NET Core web app (.NET 5 or higher). Program.cs will then be created automatically.
.NET 4 and 5 are completely different under the hood, so this distinction is important. Rather than being an iteration, the latter was written from the ground up to be more scalable and support concepts like multiple platforms, microservices, and containers.
I need to create a new web application. The team has decided to use ASP.NET Core MVC (we all have experience with ASP.NET Framework MVC).
When going through the process of creating the new application, as per usual, I can choose to create an "Empty" project, or use a template like the "Web Application (Model-View-Controller)" application template.
I have always preferred using the Empty templates because:
I manually choose each dependency in application
I don't have to carefully delete things that I don't want included
However, I am wondering if the intention of these templates is to use them as a base template for new production applications.
This is my question:
Is the intention that new real applications that fall neatly into the "Web Application (Model-View-Controller)" category use that specific template (even though it includes extra sample files that will clearly need to be deleted)?
OR is the intention that new real applications start with a blank application and only include the dependencies you actually need, while the templates are more for learning/experimenting?
Answer: It would be better to use the MVC one since the project structure in the new ASP.NET Core is easy and clear and there are no longer complex configuration files or settings implicitly handled by Visual Studio. Everything (except the project files) in the MVC template is configured with C# code in a form of Fluent API. The initial contents in the MVC template are just a demo for how it work with the fresh new ASP.NET Core which can be very useful for ASP.NET developers to learn the whole structure and pipeline things of a simple ASP.NET Core application. And you can remove everything easily and completely whenever you want.
By the way, "ASP.NET Framework MVC" does not exist for the old one that works with .NET Framework is named "ASP.NET MVC", and the new one called "ASP.NET Core" does not target .NET Core but .NET Standard, which means it works with both .NET Framework and .NET Core.
Additionally, It would be a better practice to use VSCode and .NET Core SDK with its command line tools than to use Visual Studio. It is light, portable, fully featured, and works more natively with portable things like batch scripts for automatic building, publishing and deploying on Linux.
Since the ConfigurationManager doesn't exist in .NET Standard, what is the best way to retrieve application settings for the executing assembly, whether it be a web.config or an appSettings.{env}.json, within a .NET standard class library?
We have three projects:
ASP.NET Core Web App (1.1)
ASP.NET Web App (4.6.1 )
.NET Standard Class Library (1.4) -> Referenced by both projects
In the .NET Standard class lib, we have a URL which needs to change based on the environment it's deployed to.
This is fine for the .NET Core app, we simply add the URLs to the appropriate appSettings.{env}.json file, add the appropriate values to the DI container, then use the Microsoft.Extensions.Options library to retrieve the configuration.
However, we also need to call the library from our .NET Framework 4.6.1 application, but since there is no method (at least none that I could find) to retrieve the values from a web.config file, we don't have a good way to set the URL within the class library.
We've gotten around this for now by making the URL variable static and setting its value from within the Application_Start() method of each .NET Framework project we reference it from, we determine which environment it is via an appSetting key we added to each web.config, then manually set the URL based on the environment.
Is there a more robust way to handle retrieving appSettings values from both a .NET Core and .NET Framework application within a .NET Standard class library?
Preferably where we can set the value solely within the class library.
You should read the value from configuration before calling your library, and pass it by parameter, either into a method or constructor.
In general, library code shouldn't depend on side effects from the configuration of its host environment. Doing so makes it very difficult to reuse code, or to test effectively.
Visual Studio 2015 + all updates.
Asp .Net Web application (MVC).
I start off by adding a few class libraries and separating the Asp .Net WA into layers i.e. DataAccess, Business Logic and the web project itself.
Once separated I add relevant references and everything is working as I expect it to be (i.e. the application functions as it did before I separated it into layers).
In my BL (Controllers are found here). I don't have the option to Add a Controller, like you would when right clicking the Controllers folder in the default project, so add the below line
<ProjectTypeGuids>{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}</ProjectTypeGuids>
to the csproj file for my class library and the Add Controller option now appears. Create a controller but throws an error which was due to not having a web.config file - add this file and all works (although it would be nice to have this library working without a web.config file).
The problem I've hit is, when the Controller is created it also adds a View template within the class library but my Views folder is located in my web project.
Have I done this wrong? Is there a workaround so when a controller is created, it also creates the Views into the correct project? Or another approach for this?
This is just a guess, but it seems like you are try to use a UI-based architectural pattern to build your business layer.
Typically, your models, views, and controllers are all maintained in the main web-app project. Any supporting functions (like your BL and DL) are added via class libraries. The Visual Studio MVC templates are built around that concept, which is why you had to manually add support with the GUID - and why it automatically creates the view.
If I may ask, why are you trying to build controllers into your BL? If you are trying to decouple your UI from your server code, perhaps WebAPI would be a better option.
UPDATE - A few helpful links
ProDinner - ASP.NET MVC Sample App
N Layered App with Entity Framework, Autofac, ASP.NET MVC and Unit Testing
Architecture Guide: ASP.NET MVC Framework + N-tier + Entity Framework and Many More
Most of your issues boil down to using the scaffold. The scaffold is great when you're just starting out or for extremely simple projects, but it quickly falls down beyond that. Specifically, adding a controller via scaffold is designed for an MVC project, so it expects to find things you'd find in an MVC project. Additionally, it creates scaffolded views in an appropriate directory in Views because, again, that's what it's designed to do.
The simplest solution, then, is to just not use the scaffolds. A controller is just a class that inherits from Controller. Nothing special there. Then, you can create the views where you want to create them.
I have an ASP.NET MVC 5 web application, using ASP.NET Identity 2.1. I'm trying to move all the identification / authorization code out of the web project into a class library.
I moved all the boilerplate UserManager, SigninManager stuff out, and removed all the NuGet packages for ASP.NET Identity and OWIN from the web project (adding those to the class library).
I also moved the code from the Startup.cs and Startup.Auth.cs files into my class library. These contain the OWIN configuration stuff.
How do I now ensure that this code is invoked when the application starts up? In the original project, the Startup class (in Startup.cs) had a line like this:
[assembly: OwinStartupAttribute(typeof(WebApplication1.Startup))]
I've put a similar line (with the correct class name) in the equivalent file in my class library, but that seems to have no effect. Does this line have to go in the web app? (I which case, presumably I'd need to add the OWIN NuGet package back into the web project - something I'd hoped to avoid).
I also tried adding this to my web.config file:
<add key="owin:appStartup" value="MyClassLibrary.MyNamespace.Startup, My.DLL.Name" />
But again, I'm not sure exactly how that would work without something within the web project triggering it - which again comes back to adding OWIN to the web project.
I'm so confused - any help would be appreciated.
From the http://haacked.com/archive/2010/05/16/three-hidden-extensibility-gems-in-asp-net-4.aspx/
PreApplicationStartMethodAttribute
This new attribute allows you to have code run way early in the ASP.NET pipeline as an application starts up. I mean way early, even before Application_Start.
PreApplicationStartMethodAttribute is where Microsoft.Owin.Host.systemWeb gets initialised. Hence you need to add reference to Microsoft.Owin.Host.systemWeb in your web app.