I'm developing a .NET Core project. Yesterday, Web.CodeGeneration was updated automatically. After the update, I get an error when I try to add new view to my project:
"Scaffolding Failed"
"Could not load information for project X"
I tried to remove and re-install all nuget packages again, and I checked package versions and all of them are 6.0.9 so, same version.
I tried to create a new project to test "add view", but when I install Entity Framework Core packages with web.codegeneration in the test, project, I again get the same error.
How to fix it?
Unload all your class libraries/other projects except for your web application then try re-adding any scaffolded items. This is the current workaround that works on my end, at least until this bug gets fixed.
Update:
Bug is patched with the Microsoft.VisualStudio.Web.CodeGeneration.Design 6.0.10
EDIT - Fixed in 6.0.10, if you are experiencing this issue make sure you update the packages.
The issue has been reported and is a bug in the scaffolding code.
The suggested workaround is to scaffold in a new solution/project with the same name(s) and then copy the files over:
Make new project with same solution and project name and add DB context and
other necessary thing than scaffold then the new added files add in the
main project you are making, now you are good to go.
Unloading the linked projects as suggested by others works, provided you don't have your models in separate class projects.
Otherwise we will have to wait
Remove all project references in the project you are working on, then you won't get error. After adding Areas etc. you can again add project references
If you create references to other projects, the error returns. Importing the libraries works, but if you reference them it gives an error
This isn't actually an answer, but I'm too new to leave a comment. I just wanted to pass along some information that I found useful.
I was having an issue scaffolding my MVC Controller, with views, when my Library was unloaded, even though I kept the reference. This bug is also being discussed on GitHub, and Deepak Joy Jose uploaded this video showing the workaround: Scaffolding Workaround It's for identity scaffolding issues, but the same logic applies to controllers. It's a long workaround, but it did work for my issue.
I'm trying to use Blazor WebAssembly hosted by ASP.NET Core. After implementing a page, I saw in Chrome DevTools many of unnecessary dlls are transmitted to client.
There is an example of situation. Let's assume we have following structure of projects in the solution:
BlazorApp.Client (contains Blazor pages)
Reference to BlazorApp.Shared
BlazorApp.Server (contains ASP.NET core)
Reference to BlazorApp.Client
Reference to BlazorApp.Shared
BlazorApp.Shared (contains shared classes)
Reference to ClassLibrary
ClassLibrary (contains some more shared classes)
NuGet reference to AWSSDK.Core
MyEnum.cs (enum, which is used in Blazor page; not using AWS SDK)
So basically BlazorApp.Shared project has reference to some other project, which could have many nuget packages. Minimum code to reproduce the issue is available in repo https://github.com/GTmAster/blazor-treeshake
My assumption is Mono Linker does a tree shaking in Release build, so all unused code and libraries will be excluded from resulting web assembly.
But when I run my app, I see it loads AWSSDK.Core.dll from the server:
Code in BlazorApp.Client doesn't used it, as well as the code in BlazorApp.Server and in BlazorApp.Shared. It is only loaded, because it is referenced in ClassLibrary.
Am I getting the wrong idea about Mono Linker tree shaking?
Is the only way to exclude this dll from shipping is to move MyEnum to BlazorApp.Shared and break BlazorApp.Shared -> ClassLibrary reference?
I've been investigating this too. It seems that the Linker doesn't do what you expect it to.
https://github.com/dotnet/aspnetcore/issues/28546#issuecomment-742100867
By default Blazor (and all of .NET Core) does not trim application code, it only trims the framework. There are patterns of code that are problematic with trimming. The runtime libraries have been updated and tested to make sure they play well with trimming, arbitrary libraries or user code might not be.
Upon further digging, it seems like you'd need to use Trimming to get further reductions in size. But I found this article, which at the bottom states:
The following trimming approach is being taken for Blazor Apps in .NET 5:
Assemblies from the shared framework/runtimepack get member-level
trimming
Microsoft.Extensions.* assemblies get type-level trimming
from TrimMode=Link
Assemblies from Microsoft.AspNetCore.* are trimmed
via hand generated XML file
All other assemblies are not trimmed
All in all means that the Linker / Trimming isn't going to remove unused assemblies as that's not what it does. It essentially just trims stuff out of the Framework assemblies that it believes you do not need.
You are right, the mono linker is tree shaking.
The only relevant information I could find is here: https://devblogs.microsoft.com/aspnet/blazor-webassembly-3-2-0-preview-2-release-now-available/
You may notice with this preview release that the download size of the app during development is now a bit larger, but build times are faster. This is because we no longer run the .NET IL linker during development to remove unused code. In previous Blazor previews we ran the linker on every build, which slowed down development.
So as it is stated:
Now we only run the linker for release builds, which are typically done as part of publishing the app.
Are you looking into release builds?
Try following the this advise if you want tree shaking in debug builds.
If you prefer to still run the .NET IL linker on each build during development, you can turn it on by adding <BlazorWebAssemblyEnableLinking>true</BlazorWebAssemblyEnableLinking> to your project file.
I have a huge solution with many projects and in-house NuGet packages that has a pervasive dependency on Unity 4.0.1. We are evaluating migrating this solution to Unity 5.11.1 to improve performance and solve random DI-related crashes stemming from code that the Unity project outright deleted on the 5.0.0 release.
In searching for a way to ease the migration from the outside-in two tools have been developed:
A Roslyn-based source code converter
A bridge that implements the Unity 5 interface but in reality maps calls transparently to a wrapped Unity 4 container interface
Both tools pass their unit tests just fine and the converter managed to convert one key "leaf" project, however, we've hit a roadblock when trying to reference migrated leaf project from one inner project: The infamous NU1605.
I absolutely can see how the NU106 error is warranted, as the inner project still references Unity 4.0.1 and the leaf project references Unity 5.11.1. however, this is one case of the tools getting in our way: I require both versions to "co-exist", as I am manually bridging their inconsistencies.
On paper, this should be plenty viable as the DLLs have different versions and even namespaces are different.
Is there any way to "force" nuget into accepting this weird setup?
You have two options to suppress that code. One is to use the <NoWarn>NU1605</NoWarn> msbuild property (must be defined inside a PropertyGroup). Visual Studio's project properties probably has a way to edit it in the UI.
The other option is to add the NoWarn="NU1605" metadata to your ProjectReference item:
<ProjectReference Include="package id" Version="1.2.3" NoWarn="NU1605" />
Finally, NuGet actually reports NU1605 as a warning, which you might notice if you read the docs page title carefully. The .NET Core SDK elevates it to a warning using the WarningsAsErrors property. So, if you're sufficiently proficient with MSBuild, you could either remove it after they add it, or check how to prevent it from being added to the list. My guess as to the motivation is because the BCL is being distributed as packages for .NET Core 1.x and 2.x (it won't for 3.x) and when there's a security update, you don't want NuGet's nearest-wins rule causing a package with a known vulnerability to be accidentally used.
I'm creating a new view off of a model.
The error message I am getting is
Error
There was an error running the selected code generator:
'Access to the path
'C:\Users\XXXXXXX\AppData\Local\Temp\SOMEGUID\EntityFramework.dll' is denied'.
I am running VS 2013 as administrator.
I looked at Is MvcScaffolding compatible with VS 2013 RC by command line? but this didn't seem to resolve the issue.
VS2013
C#5
MVC5
Brand new project started in VS 2013.
VS2013 Error: There was an error running the selected code generator:
' A configuration for type 'SolutionName.Model.SalesOrder' has already
been added ...'
I had this problem while working through a Pluralsight Course "Parent-Child Data with EF, MVC, Knockout, Ajax, and Validation". I was trying to add a New Scaffolded Item using the template MVC 5 Controller with views, using Entity Framework.
The Data Context class I was using including an override of the OnModelCreating method. The override was required to add some explicit database column configurations where the EF defaults were not adequate. This override was simple, worked and no bugs, but (as noted above) it did interfere with the Controller scaffolding code generation.
Solution that worked for me:
1 - I removed (commented out) my OnModelCreating override and the scaffolding template completed with no error messages - my controller code was generated as expected.
2 - However, trying to build the project choked because 'The model had changed'. Since my controller code was was now properly generated, I restored (un-commented) the OnModelCreating override and the project built and ran successfully.
Problem was with a corrupted web.config and package directory.
I created the new project, and copied my code files over to the new working project, I later went back and ran diffs on the config files and a folder diff on the project itself.
The problem was that the updates had highly junked up my config file with lots of update artifacts that I ended up clearing out.
The second problem was that the old project also kept hanging onto older DLLs that were supposed to be wiped with the application of the Nuget package. So I wiped the obj and bin folders, then the package folder. After that was done, I was able to get the older project repaired and building cleanly.
I have not looked into why the config file or the package folder was so borked, but I'm assuming it is one of two things.
Possibly the nuget package has a flaw
The TFS source control blocked nuget from properly updating the various dependencies.
Since then, before applying any updates, I check out everything. However, since I have not updated EF in a while, I no evidence that this has resolved my EF or scaffolding issue.
I was able to resolve this issue and have a little better understanding of what was going on. The best part is that I am able to recreate the issue and fix it to be sure of my explanation here.
The resolution was to install exactly same version of Entity Framework for both Data Access Layer project and the Web Project.
My data access layer had Entity Framework v6.0.2 installed using NuGet, the web project did not have Entity Framework installed. When trying to create a Web API Controller with Entity Framework template Entity Framework gets installed automatically but its one of the older version 6.0.0. I was surprised to see two version of Entity Framework installed, newer on my Data Layer project and older on my Web Project. Once, I removed the older version and installed the newer version on Web Project the problem went away.
I tried every answer on every website I found, and nothing worked... until this. Posting late in case anyone like me comes along and has the same frustrating experience as I have.
My issue was similar to many here, generic error message when trying to use scaffolding to try and add a new controller (ef6, webapi). I initially was able to use scaffolding for about 15 controllers, after that it just stopped working one day.
Final Solution:
Open your working folder on your hard drive for your solution.
Delete everything inside the BIN folder
Delete everything inside the OBJ folder
Clean Solution, Rebuild Solution, Add Controller via scaffolding
Voila! (for me)
I checked all my projects and each had the same version of Entity Framework. In my case, the problem was that one of my projects was targeting .Net 4.0 while the rest were .Net 4.5.
Solution:
For each project in solution Project->Properties->Application: Set Target Framework to .Net 4.5 (or whatever you need).
Tools->Manage NuGet Package for Solution. Find Installed “Entity Framework”. And click Manage. Uncheck all projects (note the projects that require EF). Now, Re-Manage EF and check that projects that you need.
Clean and Rebuild Solution.
This is typically caused by an invalid Web.config file. I had the same problem and it turned out I inadvertently changed the HTML comment block <!-- --> to a server side comment block #* *# (through a Replace All action).
And in case you are developing a WinForms application, try to look to App.config.
I have the exact same problem.
First encountered this while following along the Pluralsight Course "Parent-Child Data with EF, MVC, Knockout, Ajax, and Validation".
I am using MVC 5, EF 6.1.1 and framework 4.5.2.
Even after updating my VS2013 to update 4, this error still persisted.
Was able to circumvent this annoying problem by changing the DbSet to IDbSet inside the DbContext class.
Answer was originally from here.
//From
public DbSet SalesOrders { get; set; }
//To
public IDbSet SalesOrders { get; set; }
What worked for me to resolve this: Close Solution, And open the project by clicking project file and not the solution file, add your controller, and bobs your uncle
None of the above helped for me.
I found that the cause of my problem was overriding OnModelCreating in my context class that the scaffold item was dependent on. By commenting out this method, then the scaffolding works.
I do wish Microsoft would release less buggy code.
There was an error running the selected code generator:
'Failed to upgrade dependency information for the project. Please restore the project and try again.'
Steps:
Go to your project and update all NuGet packages to latest version.
Build your application till Build success.
Close solution and reopen same.
And try to add file like controller, class, etc.
I have seen this error with a new MVC5 project when referencing a model from a different project. Checking the path, EntityFramework.dll did exist. It was read-only though. Process monitor showed that there was an error attempting to delete the file. Setting the EntityFramework.dll in my packages folder (copy stored in source control) to writeable got around this error but brought up another one saying that it couldn't load the EntityFramework assembly because it didn't match the one referenced. My model class was defined in a different project that was using an older version of the entity framework. The MVC5 project was referencing EF 6 while the model was from a project references EF 4.4. Upgrading to EF 6 in the model's project fixed it for me.
For us it has something to do with build configurations, where we have a Debug|x64 build configuration that we had recently switched to using, which in retrospect seemed to be when the scaffolding stopped working.
(I suspect that there are at least 10 different things that can cause this, as evidenced by the various answers on SO that some people find to work for them--but which don't work for others, so I'm not suggesting my solution will work for everyone).
What worked for us (using VS 2013 Express for Web on 64 bit Windows 7):
It (scaffolding) was NOT working in Debug|x64 Build configuration. But doing the following (and it seems like every step is necessary--couldn't figure out how to do it in a more streamlined way) seems to work for us.
First, switch to Debug|x86--use Solution (right-click) Configuration Manager for all the projects in your solution. (Debug|Any CPU may also work).
Clean your solution.
Shut down Visual Studio. (cannot get it to work if I skip this).
Open Visual Studio.
Open your solution.
Build your solution.
Now try adding scaffolding items; for us, it worked at this point, we no longer got the error message saying something about "There was an error running the selected code generator".
If you need to switch back to a scaffolding-non-working build configuration, you can do so, after you've scaffolded everything you need to for the moment. We switched back to our Debug|x64 after scaffolding what we needed to.
I had this problem when trying to add an Api Controller to my MVC ASP.NET web app for a completely different reason than the other answers given. I had accidentally included a StringLength attribute with an IndexAttribute declaration for an integer property due to a copy and paste operation:
[Index]
[IndexAttribute("NumTrainingPasses", 0), StringLength(50)]
public int NumTrainingPasses { get; set; }
Once I got rid of the IndexAttribute declaration I was able to add an Api Controller for the Model that contained the offending property (NumTrainingPasses).
To help the search engines, here is the full error message I got before I fixed the problem:
There was an error running the selected code generator:
Unable to retrieve metadata for 'Owner.Models.MainRecord'. The property
'NumTrainingPasses' is not a String or Byte array. Length can only be
configured for String or Byte array properties.
This is usually related to a format of your Web.config
Rebuild solution and lookup under Errors, tab Messages.
If you have any format problems with a web.config you will see it there.
Fix it and try again.
Example: I had connectionstring instead of connectionString
My issue was similar to many experience here, generic error message when trying to add a new view or use scaffolding to add a new controller.
I found out that MVC 5 and EF 6 modelbuilder are not good friends:
My Solution:
Comment out modelBuilder in your Context class.
Clean Solution, Rebuild Solution.
Add view and Controller via scaffolding
Uncomment modelbuilder.
In case it helps anyone, I renamed the namespace that the model resided in, then rebuilt the project, then renamed it back again, and rebuilt, and then it worked.
I often run into this error working with MVC5 and EF when I create the models and context in a separate project (My data access layer) and I forget to add the context connection string to the MVC project's Web.Config.
I am also having this issue with MSVS2013 Update 4 and EF 6.0
The message I was getting was:
there was an error running the selected code generator.
A configuration for type XXXX has already been added ...[]
I have a model with around 10 classes. I scaffolded elements at the beginning of the project with no problems.
After some days adding functionality, I tried to scaffold another class from the model, but an error was keeping me from doing it.
I have tried to update MSVS from update 2 to update 4, comment out my OnModelCreating method and other ideas proposed with no luck.
As a temporary way to continue with the project, I created a different asp.net project, pasted there my model classes (I am using fluent api, so there is little annotation on them) and successfully created my controller and views.
After that, I pasted back the created classes to the original project and corrected some mistakes (mainly dbset names).
It seems to be working, although I suppose that I will still find mistakes related to relationships between classes (due to the lack of fluent configuration when created).
I hope this helps to other users.
This happened to me when I attempted to create a new scaffold outside of the top level folder for a given Area.
MyArea
| - File.cs (tried to create a new scaffold here. Failure.)
I simply re-selected my area and the problem went away:
AyArea (Add => new scaffold item)
Note that after scaffold generation you are taken to a place where you will not be able to create a new scaffold without re-selecting the area first (in VS 2013 at least).
vs2013 update 4
ef 5.0.0
ibm db2connector 10.5 fp 5
change the web.config file as such:
removed the provider/s from ef tag:
<entityFramework>
</entityFramework>
added connection string tags under config sections:
</configSections>
<connectionStrings>
<add name=".." connectionString="..." providerName="System.Data.EntityClient" />
</connectionStrings>
I had the same problem when in my MVC app EF reference property (in Properties window) "Specific version" was marked as False and in my other project (containing DBContext and models) which was refrenced from MVC app that EF reference property was marked as True. When I marked it as False everything was fine.
In my case, I was trying to scaffold Identity elements and none of the above worked. The solution was simply to open Visual Studio with Administrator privileges.
Rebuild the solution works for me. before rebuild, I find references number of my 'ApplicationDbContext' is zero, that is impossible, so rebuild solution, everything is OK now.
I had this issue in VS 2017. I had Platform target (in project properties>Build>General) set to "x64". Scaffolding started working after changing it to "Any CPU".
It may be due to differences in the versions of nuget packages. See if you have this by going to dependencies->nuget packages folder in your solution. Try installing all of them of a single version and restart the visual studio after cleaning the componentmodelcache folder as mentioned above. This should the get the work done for you.