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.
Related
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.
We use Visual Studio to write and maintain native Windows apps. We are looking into using NuGet to handle our dependencies, which consist of native static libs.
After some research, I've managed to use NuGet, package.config and the CoApp PowerShell scripts to create and consume NuGet packages with native libs in them. The issue we're facing right now is that we need to have Snapshot support.
The rollover PreRelease mechanism (with * for version rollover) that NuGet 3 and onwards supports looks great, however, it seems to only work with project.json and not with package.config. Project.json, however, doesn't seem to work with native packages, as they don't get installed in the local solution folder so the build can't find the headers and libs.
The question boils down to:
Is there a way to use project.json and NuGet 3 with native static libs?
If not, then, what alternatives are out there to support this use case? (The use case being build-time dependency distribution for native, unmanaged Windows static libraries).
EDIT:
At the end, we decided to use Maven for dependency management since NuGet doesn't seem to support our use case. I filed an issue about two weeks ago but it hasn't received any response. However, if we had decided to force NuGet into our use case, the solution proposed by Wendy would probably be the way to go, so I'm accepting it.
There are two ways could add content files into project that uses project.json file. One is "contentFiles" node and another is "files" node in nuspec file. Detailed steps please refer to:
http://blog.nuget.org/20160126/nuget-contentFiles-demystified.html
But please note, these ways only support UWP and Portable class libraries.
This feature is only for packages that will be installed to projects that are managed using a project.json file. Currently only two projects types are managed by a project.json.
1.UWP apps
2.Portable class libraries
The contentFiles option is not available for other project types
If you are using .NET Core application or other type project that use project.json, the content files in nuget package is not supported added into project at present.
We have several different teams building C# applications with Visual Studio. When we want to share libraries across teams, we create nuget packages for the libraries and add them to a local nuget feed.
The process we use to package our libraries is very simple: we create a .nuspec for the library, and then run nuget on the project .csproj to create the package.
This results in a package that is specific to the .Net version (4.0, 4.5, 4.5.1) selected for the .csproj for the project. We've pretty much standardized on 4.5 to deal with this.
Many publicly available nuget packages provide simultaneous support for different library versions, and we'd like our packages to do the same to make it easy for each of our teams to select .Net versions appropriate for them. I know in principle how to build a package this way-- but it involves moving files around to different folders and invoking the nuget packager at a lower-level. I don't know of a way to automate this in a way that could be picked up easily across our teams.
So my question is: is there an easy/standard way of setting up a library project in Visual Studio so it produces a cross-version-compatible Nuget package?
Not a direct answer to your question, I know this, but...
Why target multiple versions of the framework at all?
When NuGet installs a package that has multiple assembly versions, it
tries to match the framework name of the assembly with the target
framework of the project. If a match is not found, NuGet copies the
assembly that's for the highest version that is less than or equal to
the project's target framework.
Matching assembly version to the target framework of a project
What we've done is figure out what our lowest common denominator is, both for our libraries and our organization. In our case, we have some older apps still running on the 3.5 framework, so any NuGet packages we have that need to be available to any/all projects also target the 3.5 framework. However, we also have a few libraries that are only needed by some newer apps, these target 4.5 (both the projects and the libraries). This lets us leverage newer features.
If we find ourselves in a situation where an older app needs to reference a package that must reference the newest version to work, we bite the bullet and upgrade the project. However, for our libraries/packages, we always target the oldest version possible. Basically, the split is where we want/need to leverage Async/Await.
TL;DR: Don't target multiple frameworks. Target the lowest common denominator. It provides motivation to upgrade those apps lagging behind on 3.5 or 4. (Or, God forbid, 2.0...)
If you really need to support different framework versions, you will first have to create different configurations for each framework version (in your .csproj files), utilizing the configuration manager. Similar to the standard configurations "Debug" and "Release", or "x86_Debug" etc. you can add configurations by yourself like Release_Fw_40, Release_Fw_45, Release_Fw_451.
When packaging with Nuget, you can use the parameter
-Prop Configuration=Release_Fw_40
to choose which configuration you want to build, as described in the Nuget docs. There are also some hints how to automate the package builds, including support of different configurations.
Note that this will impose some additional effort for your library maintainers to manage those many configurations. It should be obvious that even if you provide a "Fw 4.5.1" version of your lib, you can only use Fw 4.0 features in the source code as long as you want to support a Fw 4.0 configuration. So make sure what you are trying is really worth the hassle.
I know in principle how to build a package this way-- but it involves moving files around to different folders and invoking the nuget packager at a lower-level. I don't know of a way to automate this in a way that could be picked up easily across our teams
I am not sure what you meant by this sentence, maybe I am telling you only things you already knew. But "moving files around to different folders" and "invoking the nuget packager at a lower-level" are things which can be very easily scripted. For such tasks, you can use simple Windows shell scripting or Powershell scripting, whatever you prefer.
I'm trying to make a portable class library in VS2010. By default, it seems to be targeting .NET Framework 4 and higher. I need to target 4.03 or higher because I need some features that were added (System.Xml.Linq). But when I try to change the target framework, the change doesn't work. I get this dialog:
I can choose one of the other frameworks and say OK, but when I look again, it's set back to the same Framework 4.0 setting, and my code using the 4.03 features still doesn't compile. What's going on here?
Update: It does let me choose 4.5 as long as I don't choose Mono for Android or VS Mono Touch. It looks like something in those libraries requires 4.0, but I don't understand why, since 4.5 is backwards compatible. And this is for use in Mono, so I need those.
I figured this out with some hacking of the configuration files for the portable framework. First, read this post about how to add library support for PCL's for MonoDroid and this one to do a similar thing for MonoTouch.
In the .csproj file for the PCL project, I found this line:
<TargetFrameworkProfile>Profile95</TargetFrameworkProfile>
which points to this folder:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETPortable\v4.0\Profile\Profile95
In that folder, there's a subfolder called SupportedFrameworks and this was missing the magic files MonoAndroid,Version=v1.6+.xml and VSMonoTouch,Version=v1.0+.xml. I added these, as described in the linked post, and now it works.
I've implemented the ability to pick and choose the PCL profile constraints in MonoDevelop in git master, but it has not yet been released.
I believe these features will be included in MonoDevelop 3.1.0
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.