I'm working on a C# web API solution, using .Net Core 3.1 and EF Core 3.1.10.
When scaffolding a controller from a class and a controller, I get this error:
Running the generator 'controller'...
The item specified is not the element of a list.
It this an EF bug?
Or should I look at the class I'm scaffolding?
Cheers, B.
Found the solution.
Turns out the context missed some things, a constructor and a DbSet. Adding those fixed the problem.
Related
I created a new project with the template "Console App (.NET Core)".
So when I try manually referencing System.Web through "Add reference", there will be no reference tab.
Can anyone help how to add reference of HttpContext?
enter image description here
The System.Web based HttpContext is a class in .NET Framework (versions 1-4) and not available in either .NET Core (Version 1-3) or .NET (version 5 or 6).
In a console application the current HttpContext will always be null. If you are creating a .NET Core web application, you can read the documentation in the following link to access current HttpContext.
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/http-context?view=aspnetcore-6.0
May be if you provide more details about what you are trying to achieve by using HttpContext in a console application, you will get a better answer.
I am converting my .net application to .net core and have come across a few errors.
can i please know on how to resolve the on Action execution as well as the URL error.
Can I please get your help to resolve them.
1.Changing the access modifier of a method in a derived type is not allowed. You should change protected to public.
2.The HttpRequest object is different in ASP.NET Core. It no longer contains Url property.
By using:
using Microsoft.AspNetCore.Http.Extensions;
then you can get the full http request url by executing:
HttpContext.Request.GetEncodedUrl();
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.
In .NET 4.7.2 Microsoft introduced the ability to use constructor injection in WebForms through the use of HttpRuntime.WebObjectActivator as seen here
The example given is in C#. I am working on a legacy VB.NET app that is in the process of being modernized. We would like to use constructor injection over the property injection we had been planning on using because it is more canonical.
However, when I attempt to give a WebForm a parameterized constructor I get the following error.
(BC30387) Class 'testpage_aspx' must declare a 'Sub New' because its base class 'TestPage' does not have an accessible 'Sub New' that can be called with no arguments.
This seems to be due to the way that VB.NET handles constructors and inheritance. With the way VB.NET handles constructors is having parameterized constructors in a VB.NET WebForms project even possible?
Did you target the app to 4.7.2 in web.config? Something like below. Constructor injection can't be used in Page/Controls in website project(the project type that doesn't have vbproj file), since the base type of the Page/Controls are unknown when generating code for Pages/Controls.
<httpRuntime targetFramework="4.7.2"/>
Edit:
Here is a blog post about how to use Unity in the exiting WebForms app.
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.