I have an ASP.NET MVC project which references a whole bunch of assemblies - some of it are targeting .NET standard while the rest are on .NET framework.
Is there an easy way to get a list of all my referenced assemblies and the .NET version they target? (I already know how to check them one-by-one - but is a productivity killer)
Perhaps a tool/script could look into the bin folder where all the dlls are and figure this out?
I do have dotPeek, but not sure if it helps.
This SO question is using a PS script to do this on a specific dll - can it be extended to all the dlls in a folder?
Related
I'm building an ASP.NET MVC app with VS 2017, targeting .NET 4.7, and I'm trying to build my models inside of business library being referenced by the web application. So I'm trying to get many of the same classes that come with an MVC project by default into a brand new class library.
Particularly, I'm getting the following error:
This is very different from the previous times this question was posted:
The type or namespace name 'IClientValidatable' could not be found
The type or namespace name 'IClientValidatable' could not be found (are you missing a using directive or an assembly reference?)
Namely, in that they both are solved simply by including the using statement for System.Web.Mvc where IClientValidatable lives.
But I've definitely already done that... Here's the reference manager for the class library with the reference included available for .NET 4.7
As further proof, here's a side by side example of where I can pull in some classes from System.Web.Mvc, but not IClientValidatable
For reference sake, here's the configuration on the class library itself
So did this class move somewhere? Is it available with .NET 4.7?
So the real question seems to be not where did it go, but why the most recent framework is targeting such an old version.
When trying to add a reference to System.Web.MVC while targeting .NET Framework 4.7, the only available option is MVC v2.0.0.0 which is incredibly old. When seeding a new MVC app, it'll come with v5.2.3.0
Here's the Assembly Explorer with both libraries loaded. Common items will be highlighted in each, but IClientValidatable wasn't added until later.
And here's the VS 2017 Reference Manager where you can add references based on your current framework, showing the old MVC library for the new .NET version.
So the question then becomes....
Q: How can I add a reference that is not available in the list of assemblies for my framework?
A: Same way you'd add any other reference - you can browse to a dll or grab it from nuget.
DLL If you already have a web app, there are good odds you can find the dll in your existing packages directory at something like:
\packages\Microsoft.AspNet.Mvc.5.2.3\lib\net45\System.Web.Mvc.dll
If you prefer Nuget, some minor annoyances are that nuget package names don't exactly sync up with the assemblies they install, it's not easy to browse or search which assemblies come with which packages, and they libraries and frameworks often come bundled with other things you might not need. All that said, you'll be looking for the package called:
Microsoft.AspNet.Mvc on Nuget
Which will install the following libraries:
I have a project I was brought onto a few years ago and the original developer is no longer available. We have an Umbraco 6 based website. The solution has two projects, a Web Site and a class library call Umbraco.Extensions. I believe I read some conventional wisdom pertaining to Umbraco at some point where it is recommended to split it up like this but I am looking for more information about this particular style of setup and how it is supposed to work. For example right now I am dealing with a missing assembly issue, and i fixed it by copying a dll from the bin of Extensions to the bin of the Web Site. How is this handled regularly?
it's generally a good idea to keep the projects separated. You should have some kind of automation (maybe a post-build action) to copy the dll of the class library to the bin of the umbraco project. Or maybe rebuild the umbraco project with the correct references, but I dont usually do that.
I'm trying to add .net 45 reference to a asp.net 5 starter web project..and i'm getting this errors.
While it is true that you can target multiple frameworks in a way similar to how you've done in your example, I think you will probably not be able to get the StarterWeb project to run under .NET 4.5 without some significant changes.
When dealing with multiple frameworks, Visual Studio 2015 will actually provide a lot of help if you hover the mouse over the code with errors:
One obvious difficulty in getting the StarterWeb project working is that between MVC 5 and 6, a number of pieces have been moved into new namespaces and broken up into different assemblies. Most notably, the MVC 5 package depends on System.Web, whereas the 6.0 beta that is used by the StarterWeb project does not. With the MVC libraries moved, the Authorize attribute is now in Microsoft.Aspnet.Mvc, whereas in earlier versions it belonged to System.Web.Mvc.
While in theory you could probably target different versions of MVC across the frameworks, in practice that would probably not be worth the trouble. Even if you find Authorize, there's no guarantee that it will be the "same" one, even if it compiles.
If that is a route you want to go (or just when targeting multiple frameworks in general), you have control over which packages are used by which framework in the project.json file.
If packages are compatible with all of the targeted frameworks, you can leave them in the parent dependencies area of the project.json file, but when they are specific to a given framework, you need to add a child dependencies section to that particular framework's configuration. In the case of .NET 4.5, you can also add familiar framework assemblies (as opposed to NuGet packages) by adding a frameworkAssemblies section.
You will end up with something like this:
"dependencies": {
"SomeCommonPackage":"1.0.0"
},
"frameworks": {
"aspnet50":{
"dependencies":{
"Aspnet50SpecificPackage":"1.0.0"
},
"net45":{
"dependencies":{
"NET45SpecificPackage":"1.0.0"
},
"frameworkAssemblies":{
"System.Web":"4.0.0.0"
}
When you target these different frameworks, you will often find that at least some code will have to framework-specific. To handle this, you can add compiler directives for the various using statements and the actual code that depends on packages only available in one framework or another.
For example, you may end up with areas that look something like this:
SomeType result;
#if ASPNET50
result = SomeMethodNotAvailableIn45( );
#endif
#if NET45
result = EquivalentMethodIn45( );
#endif
Obviously that is overly simplistic, but it gives you the basic formula:
Put shared dependencies in the root dependencies section
Put dependencies specific to a given framework in its own dependencies section
Use compiler directives for framework-specific code that can't be shared
I also would recommend you take a look at Rick Strahl's excellent blog post to see a great walk-through of targeting multiple frameworks with more detail and lots of screenshots. One nice feature of the new project system is that it can easily create a NuGet package for all of the frameworks you choose to target, and he goes into more detail about that as well.
Adding a .NET 4.5 project that is in the same solution as a reference to a vNext project still doesn't work in VS2015 RTM/ASP.NET Beta5. The project just can't seem to find the source/binary and tries looking in nuget for it. I followed the recommended steps with global.json, dnx451 dependencies.
My work around was to
Make the .NET 4.5 project pack a nuget package in post build step
Add a package source location to the local package file
This way I can speed up development cycle without requiring a nuget publish. One wrinkle is that relative package source paths using a $ are replaced with absolute paths.
I'm trying to publish a solution that contains several projects -one of them is MVC- to IIS7.
When the MVC project is published and some views are being accessed I get the following error:
Could not load file or assembly 'NHibernate.Mapping.Attributes, Version=3.2.0.0, Culture=neutral, PublicKeyToken=aa95f207798dfdb4' or one of its dependencies. The system cannot find the file specified.
This happens because the view I'm trying to access is calling a function in another project in that solution and needs this library!
but this library is not contained in the MVC project!
I was able to solve it by referencing that DLL in the MVC project! but I need another solution, because it doesn't make sense to reference every single DLL in all the other projects!
I'm using the "Web Deploy" publish option for the MVC project, is there another way that I can publish it and make it work without referencing all the DLLs from all the other projects?
There is an article on how to deploy assemblies that are not referenced by your MVC project directly:
http://haacked.com/archive/2011/05/25/bin-deploying-asp-net-mvc-3.aspx
Basically you need to create a folder in your project called _bin_deployableAssemblies and add your assemblies to it. They will get deployed with the website.
Here is a quote from the article:
So here’s the kicker. If you’re building a web application, and you
need an assembly deployed but don’t want it referenced and don’t want
it checked into the bin directory, you can simply add this folder
yourself and put your own assemblies in here.
The type 'System.ComponentModel.DataAnnotations.MaxLengthAttribute'
exists in both
[path...]\packages\EntityFramework.4.3.1\lib\net40\EntityFramework.dll
and
'c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework
\.NETFramework\v4.5\System.ComponentModel.DataAnnotations.dll'
Now, I have read on msdn that its safe to exclude the EntityFramework reference (which was added through the nuget package). However, when I do that, I cant create a DBContext properly as the DbModelBuilder class lives in the EntityFramework dll. Also, some other critical classes are missing when I remove the EntityFramework refference so this is old and irrelevant solution now.
Update (disambiguation): Both System.ComponentModel.DataAnnotations.dll and EntityFramework.dll include System.ComponentModel.DataAnnotations.MaxLengthAttribute. The problem is that each dll also includes other classes that are critical to EF code-first design. For example:
EntityFramework.dll:
- System.Data.Entity.DbModelBuilder
System.ComponentModel.DataAnnotations.dll:
- System.ComponentModel.DataAnnotations.RegularExpressionAttribute
Add this statement to top of your class
using System.ComponentModel.DataAnnotations;
System.ComponentModel.DataAnnotations namespace is distibuted across the EntityFramework.dll and System.ComponontModel.DataAnnotations.dll. So you need to add a reference to both of that in your project to make use of DataAnnotations.
The MaxLenth attribute is present in EntityFramework.dll. So make sure you have that reference to that dll present in your project references section.
EDIT : As of .NET framework 4.5, this namespace is moved to the System.ComponentModel.DataAnnotations.dll. So If you use .NET Framework 4.5 with Entity Framework 4.3.1 or less, You will run in to this conflict. The solution is to switch to Entity framework 1.50 beta 1/ 2 release if you want to stick with .NET 4.5 or downgrade to .NET 4 to use EntityFramework 4.3.1.
From the msdn documentations.
Starting with Entity Framework 5.0 Beta 1, the EntityFramework.dll
does not contain definitions for data annotations. These definitions
were moved to System.ComponentModel.DataAnnotations.dll and are
defined in the System.ComponentModel.DataAnnotations.Schema namespace.
I didn't have the option of upgrading the project to use EF5, or downgrading the build machine to .Net Framework 4.
There is a way to solve this though! It turns out when you install Visual Studio 2012 it adds the following folder (amongst others).
C:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0
In VS if you open a project targetting 4.0 and look at the properties of your reference to System.ComponentModel.DataAnnotations you'll see that the path is pointing to the above location, rather than the GAC.
This folder contains the original Framework 4.0 assemblies. If they're present on the machine then MSBuild etc., upon building a project targeting 4.0 will reference these rather than the modified ones that 4.5 puts into the GAC.
In our case this meant we could fix the problem by copying that folder from a dev machine with VS installed up to our build server in the same location. (N.b. We only needed to copy this folder, there was no need to install VS on the build server).
More info here: http://marcgravell.blogspot.co.uk/2012/09/iterator-blocks-missing-methods-and-net.html
Hope this helps someone else!