What is the difference between AutofacContrib.Multitenant.dll and Autofac.Extras.Multitenant.dll.
I fell both will enables multitenant DI support. Currently i am using AutofacContrib.Multitenant.dll and is not available in NuGet gallery. But Autofac.Extras.Multitenant.dll exists in NuGet gallery. Is both are same ?
Both of these are the same library. As of version 3.0, all AutofacContrib.* libraries were updated to be Autofac.Extras.*. Use the AutofacContrib versions until such time as you've upgraded your core Autofac to 3.0+, then switch over to the Autofac.Extras version. The AutofacContrib libraries were left for people who haven't upgraded yet.
Related
I have a multi-project solution that contains a data layer on .Net Standard 2.1 and a WebAPI on .Net Core 3.1. Currently, I have no plans to upgrade to .Net 5.x (Note: Core is removed in 5.x naming convention) because it is not LTS - that will be .Net 6.x. So, I will upgrade to 6.x when it comes out.
In one of my data layer solutions, the NuGet Package Manager is recommending that I upgrade Microsoft.AspNetCore.Identity.EntityFrameWorkCore from v3.1.8 to v5.0.2. It seems like the major version is moving in lockstep with the .Net major version (Note: 4.x is skipped in order to avoid confusion with the venerable .Net Framework 4.x). Should I follow the advice and upgrade?
Specifically, will this cause any problems with the .Net Core 3.1 WebAPI project? Generally, can I do this for other Microsoft.* packages that recommend upgrading to a 5.x version?
I bit the bullet and upgraded all of them. Everything works flawlessly and I am glad that I did it. There were a few breaking changes that needed to be dealt with. I recommend checking Microsoft's breaking change log here:
https://learn.microsoft.com/en-us/aspnet/core/migration/31-to-50?view=aspnetcore-5.0&tabs=visual-studio
My company has internal components that we deliver via internal NuGet. Now i want to make a Version 5.X of these components which will be breaking a lot from the 4.X versions.
However now if my colleagues browse for updates, the Nuget browser would recommend these new packages.
What i would prefer: If example 4.6 is installed, it would take the highest 4.X version but not 5.0 or above. Making packages for the 5.X path under completely different names would be annoying when the developer choses to upgrade.
Is there a way to mark nuget packages to do something like that? If that's not clear, tell me and i try to clarify.
If your projects are using packages.config, you can use allowedVersions: https://learn.microsoft.com/en-us/nuget/reference/packages-config#schema
There's no way to do this if your project uses PackageReference, but you can upvote (👍) this isse: https://github.com/NuGet/Home/issues/9082
Our company has multiple applications that are .Net Framework 4.8 and we also are growing the number of applications that are .Net Core 3.1.
We have written a whole library of NuGet packages (in a private repository) written in .Net STANDARD 2.0 that are currently consumed by both the 4.8 and Core 3.1 applications mentioned above.
Standard 2.1 offers many new language features, such as Nullables, and we want to start to migrating our NuGet packages over to Standard 2.1, but obviously need to continue to support those applications still on .Net 4.8 (which can't consume Standard 2.1).
Obviously we need to branch our source code, but what is the convention for publishing two almost identical NuGet packages, one written in 2.0 and the other 2.1?
NuGet supports multiple-target-frameworks for a package. Please refer to doc to learn more.
I get error installing documentDB nuget package.
Could not install package 'Microsoft.Azure.DocumentDB.Core 1.2.1'. You are trying to install this package into a project that targets '.NETPortable,Version=v4.5,Profile=Profile7', but the package does not contain any assembly references or content files that are compatible with that framework.
Any ideas? thanks in advance.
The Core package actually targets NetStandard 1.6, not .Net Core specifically.
NetStandard is a library that acts as API for different runtimes and it's much more powerfull than PCL because it's platform-agnostic:
This means that the DocumentDb.Core package can run on .Net Core 1.0, .Net Framework, Xamarin and UWP.
If you are creating a PCL, I would recommend you to create a NetStandard library instead.
It will let your library support a much wider universe of platforms and the great thing is that, if a new platform comes along that supports NetStandard 1.6 (for example), your library will work without needing to recompile or republish it.
This error message tells us that this assembly Microsoft.Azure.DocumentDB.Core is not supported on portable library. From this assembly nuget site, we know that This client library enables client applications targeting .NET Core to connect to the Azure DocumentDB service. If you want to use Azure DocumentDB library, please try to see if this assembly works Install-Package Microsoft.Azure.DocumentDB
I have a NuGet package for a library that is currently implemented only for .NET 4. But I have ported library code to support various platforms (WinRT, SL5, WP8) so ideally I would like to package it as a portable class library (PCL) to simplify the maintenance. But the library is using LINQ to XML (XELements etc.) that requires targeting .NET 4.0.3 and installting .NET 4.0.3 on a client machine.
So I have a dilemma regarding how to target plain .NET 4. If it was not about NuGet packages and I had a control of the user base I could simply state as a prerequisite installing .NET 4.0.3 runtime. However, I don't want to limit the user base in any way, so it looks like I will have to have two versions of the library: portable that targets .NET 4.5, SL5 and WP8 and non-portable targeting just .NET4. What's silly is that both libraries will have exactly the same code since LINQ to XML is of course supported in .NET 4, it's just PCLs that don't have such support when targeting .NET 4.
My first question is whether this seems to be a right strategy? The alternative would be to take away all XElement-dependent code from PCL and have it in non-portable parts, but this does not seem right because the code will be exactly the same for all libraries.
The second question is whether it makes sense to target .NET 4.0.3 from a PCL at all: if I have separate version targeting .NET 4 will users that have .NET 4.0.3 runtime installed gain anything from getting a PCL rather than plain .NET 4 version? I know .NET 4.0.3 has other improvements but those don't affect my library.
Yes, I think the best thing is to create two versions of your library, one targeting .NET 4 and another portable library that targets the other platforms you support. Use source file linking so you don't have to have two different copies of your source code, just two different Visual Studio projects.
You only need one NuGet package though. Put the .NET 4 version in lib/net40 and the portable version in lib/portable-net403+win8+wp8+sl5 (or whatever combination of platforms you decide to support). Then NuGet will install the right one depending on what a project is targeting. NuGet 2.1 or higher is required for this to work for the portable version.
In reference to the question about .NET 4.0.3, it's about giving the consumers of your library flexibility. The people using your library are using it to create applications. Supporting .NET 4 may not be as important to them as it is to you. By supporting .NET 4.0.3 in the portable version of your library, it means that if they choose to require .NET 4.0.3 in their apps, then they will be able to use your library from their own portable libraries and more easily share their app code across platforms.