Are you tired of checking if a newer version of the library you're using has been released, or when you update to new versions, change all references in all csproj projects?
For example, I have many csproj projects using those references:
<HintPath>..\..\..\Referencias Externas\Microsoft.Practices.EnterpriseLibrary 4.1\Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.dll</HintPath>
...more...more...
<HintPath>..\..\..\Referencias Externas\Unity 1.2\Microsoft.Practices.Unity.dll</HintPath>
...more...more...
<HintPath>..\..\..\Referencias\Company\2.0\Company.Common.dll</HintPath>
Now, I would like use new versions, EnterpriseLibrary 5.0, Unity 2.1, NHibernate 3.2, etc, and references to Company Framework (Company.Common.dll, etc), but I need changes all references in many,many projects.
any extension in VS2010 for do it easy and quick?
I would like any like ProjectConverter - Auto update DevExpress references http://www.devexpress.com/Support/Center/p/Q308968.aspx
Reference:
http://feedback.wovs.com/forums/71955-extension-ideas/suggestions/1003595-automatic-reference-update
Use the package manager nuget to manage your dependencies.
NuGet is a Visual Studio extension that makes it easy to install and update third-party libraries and tools in Visual Studio.
As a workaround, you could create a library project that does the handling and forwards access to the .dlls and every other project uses this one. Then you only need to update the .dll references in this one wrapper project.
Related
Suppose I am building two class libraries in a single solution in visual stuido. The projects are called "Core" and "Extensions".
Extensions depends upon Core.
I would like to publish these as separate nuget packages for other developers to consume, because while the Core package would always be used, the extensions package just provides some optional functionality.
When I am developing the solution in visual studio, however, it is much simpler for me to set a project dependency from Extension to Core. Otherwise (in a naive approach), building the whole solution would require the following steps:
In visual studio, commit and push Core.
Wait for the CI server to build Core and publish the nuget package to our internal feed.
In visual studio, manage nuget packages for the Extensions project.
Connect to the internal nuget feed
Get the updated Core nuget package.
This approach would work, but is obviously very tedious.
The main difficulty I have been encountering while researching how to do this is that the way all of these things interact has been changing quite rapidly over the past few years, with sdk vs non sdk style projects, nuget pack vs dotnet pack vs msbuild pack, and so on and so forth.
Perhaps the most relevant, most recent answer appears in this question How do I create an individual nuget package for each project in a solution, with project references converted to nuget dependencies? however the answer is now quite old, and is for a dot net framework style project (using packages.config), not a .net5 project.
So, can anyone provide up to date advice on how to correctly accomplish the following:
In a visual studio solution with multiple .net5 class library projects, have dependencies set up as project dependencies at dev-time, but convert each project to its own nuget package with the equivalent package dependencies at publish time.
Until recently, when creating a .Net Core project, I've been able to select what version of Core to use for it. Since a recent update of Visual Studio 2019, any library project I've created for .Net Core has defaulted to version 3.0. There do not appear to be any options during project creation to select a different version.
For the time being, I need to create projects using .Net Core 2.2, so I'm wondering if anyone knows how to get that option back. For now, I've just been manually changing the target version after creation, but that seems hacky, and I suppose it may be leaving me with bundled references I don't need, or omitting ones that I do.
Update
After installing tons of SDKs, I still do not see the option to choose a framework upon project creation. The documentation for Visual Studio 2019 shows the option as it appears for .NET Framework projects:
... but when creating .NET Core or Standard projects, I am not presented with the option to choose the version:
Is the policy, now, that all projects default to the latest, and if you want something else, you have to change it in the project properties?
I am struggling with creating NuGet packages. I am using Visual Studio 2017 Community edition.
I have seen a couple of videos that show a "Pack" option on the menu when right-clicking the project in Solution Explorer. However, I do not have that option. Is this one of the features in the other (non-Community) versions of Visual Studio? I believe I have also seen a "create NuGet package on build" option mentioned somewhere. I cannot find that either.
I have tried various ways of using nuget, dotnet, and msbuild from the command line(s), but haven't had much success. Very frustrating.
Any help is appreciated.
If you really want to use Visual Studio, I would recommend installing an extension that helps you with that problem. For example, this one. The options people have in videos depend on the extensions they have installed. For you, it is the same.
Alternatively, just use the command-line tooling for this as explained here or for .NET Core here or here.
dotnet/msbuild pack is only available for SDK-style projects, but I believe works for all versions of Visual Studio, as well as on the command line. .NET Core introduced these SDK-style projects, which can be identified by <Project Sdk="Microsoft.NET.Sdk">. If your project (.csproj if it's a C# project) doesn't have the Sdk property or import Microsoft.NET.Sdk in either of the two other ways, then it's not an SDK style project and doesn't support packing in this way. Another obvious difference between the two styles of projects is that SDK projects are only a few lines long from the new project template and don't list files in the project, whereas old style projects are typically a full screen long, even from a new project template with only a single class file, and it does list individual files in the project. If you want to continue with this project type, you'll need to use nuget.exe pack and you'll probably want to create a .nuspec file to define some of the package metadata.
However, using SDK style projects is the future, it just takes time for all of Microsoft's existing project types to migrate. It's much simpler to use, so personally I would avoid old style projects unless you're using a project type (like ASP.NET, not ASP.NET Core) that doesn't support it.
All of this is confusing for anyone new to the .NET ecosystem. My recommendation is 1. when you install Visual Studio, when making your workload selections, make sure in the component list that .NET Core is selected, whatever the newest version of .NET Core that is available at the time of installation. When creating a new project in Visual Studio, always select the .NET Core version, or .NET Standard version of any new project template, even if you want to target the (Windows) .NET Framework, in which case you edit the .csproj and change <TargetFramework>netstandard2.0</TargetFramework> to <TargetFramework>net45</TargetFramework>, although I would recommend multi-targeting possible by adding a s to the element name and using a semi-colon separated list: <TargetFrameworks>net45;netstandard2.0</TargetFrameworks>. So, avoid the "Class Library (.NET Framework)" template, instead use "Class Library (.NET Standard)" and then change the target if you have to.
#zivkan led me down the right path. Changing my project types to .Net Core from .Net Framework made all the options I mentioned in my original post available. No extensions were needed.
My .Net Core class library project now has the Pack and Publish options available on the project's context menu. In addition, there is a another tab (Package) on the project properties page. On that page there is a "Generate NuGet package on build" option along with version, name, tags and other properties.
I have done much .Net framework development, but have been ignoring .Net Core and the newer options. I guess I need to dig in and learn about them.
I need to implement few features, however, they do not seem to be possible, and I don't have a lot of implementation time.
I have a solution PCL (.NET 4.5, Profile=111) and for some reasons (that I don't understand from hours now), I can't install the following packages :
Stripe (The only one that can be installed is Stripe.net, but I can only install it on Android and iOS, not on the PCL part..)
Cloudinary (I tried all of them and... It's not compatible with .NET 4.5, Profile=111)
Do you have any idea or any work around to make it work? I need Stripe for payments and Cloudinary for images hosting. It's already what the company is using so, I have to adapt.
I was thinking about don't use any sdk and just do everything by myself, is it allowed/possible?
Both of that packages have .Net Standard targets so i would prefer to use new *.csproj vs2017 format with library targeting .Net Standard. That is not an PCL that targets .Net Standard, this is not an PCL at all.
.Net Standard library with new csproj format have some advantages like:
Ability to install old nuget packages that targeting platforms as well as new packages that targeting .Net Standard(as opposite to PCL that can install only ald packages)
Ability to edit csproj file on the fly without unloading project
Simplified csproj file
Cleaner look of dependencies
Smoother work (fewer bugs problems)
Some other stuff Im not aware of
Here is full list of changes.
For that you need to create new project from template .Net Standard->Class Library(.Net Standard). Than install all nuget packages there and link that project from your platform projects. Old PCL can be deleted. Here is some guide to migrate. Note: to install old nuget packages that targets .Net Portable you need to add in your csproj file similar lines:
<PropertyGroup>
<PackageTargetFallback>portable-net45+win8+wp8+wpa81</PackageTargetFallback>
<PackageTargetFallback>net461</PackageTargetFallback>
</PropertyGroup>
PackageTargetFallback attribute for every target framework you library needs. That will allow old packages to pass target checks.
What is the difference between a NuGet package, a Reference (is reference similar to a tool?), and a template in Visual Studio?
Why do we need them?
What is done / changed in our project when we install each one of them?
Are they dependent on each other in some way? Which one(s) of them are global installs, and which one(s) need to be installed in every project?
Before any comments or misunderstandings: this answer is NOT composed by me, but it was accepted as an answer here, so for the sake of the users trying to find an answer to this, I am literally Copying the answer to your question in this place.
What is the difference between a NuGet package, a Reference (is reference similar to a tool?), and a template in Visual Studio?
References are used to pull additional libraries into your project. For example, your colleague develop a library which implement some functions that you wanted. You needn't write it by yourself, just add the dll into your project through add reference. Of course you can add any libraries not it come from third part or from Microsoft. But it won't notice you when the libraries changed or updated.
NuGet package is the package manager for the Microsoft development platform including .NET. It will help you manage your packages which installed on your project. When the package has new version released, it will notice you to update it. The NuGet client is a tool provide the ability to produce and consume packages.
Template is similar to a sample project which provides the frameworks based on different type of project. You just need to add your content/functions into this frameworks to implement your requirement. For example, if create a WinForms project, it will reference System.Windows.Forms automatically which contains all stuffs you needed in WinForms project.
Why do we need them?
NuGet package and Reference can help us invoke some functions which have been implemented by others or some have been encapsulated by Microsoft. And the Template can help us create a project without build framework by our self. All of them help us save a lot of time when developing a project.
What is done / changed in our project when we install each one of them?
Add references in your project, it will let you invoke the functions in these references in your project.
Install NuGet packages will add the package reference into your project automatically and then you can use the functions the package provided.
The template will be installed when you install Visual Studio. Most of common templates will be installed. Then you can create a new project through these templates quickly.
Are they dependent on each other in some way? Which one(s) of them are global installs, and which one(s) need to be installed in every project?
Reference and NuGet packages need to referenced/installed on a project. But this project can be create through the templates or can be create by customer self. So in some way, reference and NuGet package are dependent on project.
Templates is global installs and NuGet packages and reference need to be install in every project.