This question describes the problem I'm having, but I'm not aware of any dependencies that Moq might have. Has anyone experienced this, or is anyone aware of Moq dependencies? Thanks!
This can happen if you're targeting the .Net Client Profile and not the full framework.
In Visual Studio, right click on your project and choose properties. Make sure your target framework is .NET 4 Framework and not .NET 4 Framework Client Profile.
It should look like this:
Related
Does OxyPlot.Wpf work on .NET Core?
My application uses .NET Framework 4.8. I am considering switching to .NET Core 3.1.5 which was released in 2020 June.
Note OxyPlot has an assembly called OxyPlot.Core but it has nothing to do with .NET Core from what information I have gathered. OxyPlot.Core is "the core library... you also need to add a platform-specific OxyPlot package". This makes it seem that OxyPlot.Wpf depends upon OxyPlot.Core and in fact if you try to uninstall OxyPlot.Core the error will be "unable to uninstall OxyPlot.Core.2.0.0 because OxyPlot.Wpf.2.0.0 depends on it". The online documentation does not seem to tell you this but fortunately NuGet will prevent the uninstall.
This means OxyPlot.Core is the core of OxyPlot and its existence does not necessarily tell you anything explicit about .NET compatibility.
I'd say yes it is compatible. Based on the nuget link https://www.nuget.org/packages/OxyPlot.Wpf
Think you Will find OxyPlot works fine with Wpf .NET Core .. but I cannot say the same for a Winforms .NET Core project I have; at the present time I am having (the usual) enormous difficulty in making it work
I'm trying to add a full framework class library as a project reference to asp.net core 2.0 MVC project and getting the below error.
Project XYZ is not compatible with netcoreapp2.0 (.NETCoreApp,Version=v2.0).
Project XYZ supports: net462 (.NETFramework,Version=v4.6.2)
I have updated to the most recent version of Visual studio i.e, 15.3.5.
Is it even possible to reference 4.6.2 libraries in core 2.0 projects?
The first thing that you can try is to compile the library you want to consume as netstandard2.0.
Theoretically (according to the .net standard documentation), this will make it compatible with projects using net461 and later as well as netcoreapp2.0 and later.
In practice, sometimes you will end up with a problem with one of your dependencies that don't provide the same library version across different compilation targets.
In such cases you may simply need to add the .net core 2.0 as a target framework for the XYZ library.
The xml tag listing the targets is <TargetFrameworks> in the XYZ.csproj file and is not handled by the Gui of the project's properties.
So I would give a try at editing the XYZ.csproj by hand and add or replace what's listed as <TargetFrameworks> with netcoreapp2.0.
If you are adding it as additional target you need to separate them with ';' as in
<TargetFrameworks>net462;netstandard2.0;netcoreapp2.0</TargetFrameworks>
More details about this in this Microsoft doc.
Please keep in mind that this will trigger multiple compilations and will slow your build consequently...
It should be. Microsoft announced a ".NET Framework Compatibility Mode" with the release of .NET Standard 2.0. However, they didn't go into great detail about how it works exactly, or what to troubleshoot if it doesn't. Additionally, they only specific talk about it in relationship to Nuget packages, so it's possible there's some role Nuget is playing in the process, as well. Unfortunately, I've been unable to find any additional information about this feature outside of the announcement post.
That said, Microsoft's explicit recommendation is to not rely on the fact that your .NET Framework library may just happen to work in .NET Core; instead, you should be actively porting .NET Framework libraries you control to .NET Standard. I'd say you're likely going to spend more time trying to figure out why it doesn't "just work" than you would porting your code, so that it will definitely work, and be future-proof to boot.
The following solution worked for me.
Deleted bin and obj folders from all the projects in the solution, rebuild and if it still doesn't work try changing browser from debug options. for eg. If you already have chrome as default browser in Visual studio, switch to Edge or Firefox.
I've seen videos introducing ASP.NET vNext and been keeping up with the recent announcement blog posts, but detailed information on what's been stripped from the full framework appears slim. Here's what I think I know so far:
It's much smaller (11MB vs >200MB): http://davidzych.com/2014/05/24/getting-started-with-asp-net-vnext/
Strong naming is gone: http://jeremydmiller.com/2014/06/09/final-thoughts-on-nuget/
It's dumped System.Web
It includes a merged MVC and WebAPI (however I don't believe this is part of the framework itself but rather dependencies that can be specified)
Dependencies are completely managed through project.json, to the extent that the base
Are we basically looking at a framework that basically includes nothing more than what's in mscorlib in the full framework, with all else delivered via package management? And if this is the case, why would one need to target the framework specifically, as described here? http://blogs.msdn.com/b/webdev/archive/2014/06/17/dependency-injection-in-asp-net-vnext.aspx
The reason they specifically target NET45 in the link you supplied is because AutoFac is built for and has a dependency on .NET 4.5. Without NET45 the code wouldn't compile.
My assumption is that once vNext gets closer and closer to release the Autofac (and StructureMap, and Castle Windsor, and ...) will release a version that targets the cloud optimized framework to remove the dependency.
As far as I understand, .Net Framework is the fully framework we know and love with all the Windows implementations and lots of code we don't normally use, like they explain in some videos an XML parser.
In .NET Core they removed all the unneeded implementations/dependecies and only left the basic ones. which also enables cross platform (not yet), so in the future one could think as the only framework : CORE Framework, and run on any device. Their february community standup give a lots of information and insight on their objectives and goals.
I see this as a transition, when some features are available only on the full Framework while in the futures one might expect to see all features available for .NET Core.
From a Microsoft perspective, if they want to release lets say Entity Framework for mobile (EF7 is aiming at that) they must get rid of all the windows implementations, on EF and it's dependencies (Framework). So they created a non-windows dependency on the framework, which also helps the multiple framework install and remove some problems with updating the framework by having them mostly isolated from the system, lying in the application. New problems will come like multiple copies of the same framework on one machine per application, that's why they are working on something called Smart Sharing.
This post may help you and give you some insight specially this part :
The structure of .NET Core is comprised of two major components which
add to and extend the capabilities of the .NET Framework as follows:
Runtime:
Built on the same codebase as the .Net Framework CLR. Includes the
same GC and JIT (RyuJIT) Does not include features like Application
Domains or Code Access Security. The runtime is delivered on NuGet
(Microsoft.CoreCLR package)
Base class libraries:
Are the same code as the .Net Framework class libraries but do not
contain dependencies so have a smaller footprint. Available on NuGet
(System.* package)
and I guess you already read Introducing .NET Core from Microsoft.
Regarding your concern about specifying a specific framework is because right now, not everything works on Core CLR so you must choose which one to use, or you can target both and use different implementations.
As of right now, CORE only runs on Windows; the mono framework doesn't have a SQLLite provider for entity framework but it does on Core, so you can use an InMemory or Azure EF provider for example, and choose depending on the enviroment your application is running.
As Scott Gu says on the community standup, they envision a future where there's no mono framework or full framework, there's just Core, but that will take time if it ever happens.
I can't find an original source other than a comment by David Fowler (I believe) on a presentation from NDC, but CoreCLR used by the K Runtime is actually a reincarnation of the CLR used by Silverlight 2. It was used because it's small and designed to be cross platform. There is some additional information here: https://stackoverflow.com/a/25720160/113225
I know this is a rather odd question, please don't flame me :)
I have a concrete need to "downgrade" a current Asp.Net Mvc 4 (net framework 4.5) application to Asp.Net Mvc 3 (net framework 4.0) because our shared hosting provider does not support .Net 4 (I know it's crazy considering it's been in retail since 12 Aprli 2010 and first beta came out in May 2009 but it's not the point of the post).
Is there any tool, or guide, or anything that could help in the process? I'm getting a bit lost because I upgraded many
applications
but I never had to downgrade one.
I have use some of the features like begincollectionitem which may not be direct compatible to mvc3
I doubt you'll find an official guide or tool, you'll have to do it manually. Personally, I would do the following:
Start a new MVC 3 Project (MVC3 is available via nuget)
Copy your files from one to the other
Fix any compilation issues
Use the publish site feature to publish somewhere locally (this will hopefully find compilation issues in your Razor views which don't get found during the project build)
Test the site fully!
Sorry it's not more helpful, but I don't think people generally design for the downgrade process.
I've been using System.Data.OracleClient for a while now and i'm not sure whether I should keep using it if it is being deprecated?
Although all my pages will still work under the .Net 4 framework i'm worried that when there is a new framework all the pages may stop working.
Does anyone have any suggestions?
Using it is still ok for now, but what is the future of the app? Do you plan for the application to be used and maintained for years in the future? If so, you should move to ODP.net so that you get updates and new features.
Microsoft's recommendation is that you find a third-party client, such as ODP.NET.
The types in System.Data.OracleClient are deprecated. The types are supported in version 4 of the .NET Framework but will be removed in a future release. Microsoft recommends that you use a third-party Oracle provider.
http://msdn.microsoft.com/en-us/library/77d8yct7.aspx
Using the Oracle DLLs has always performed better (quicker) for me. While System.Data.OracleClient will remain in VS, I don't understand why you wouldn't want to use the Oracle DLLs.