Currently I have VS2015 SF projects. I downloaded VS2017 and try building/experimenting SF project with newer runtimes. Is this doable? My initial try did not seem to work.
The runtime is always backwards-compatible with older SF NuGet package, so just make sure your NuGet package versions are at or below the runtime that you are deploying to.
Related
In my class library, Manage Nuget Packages shows the latest stable version of Newtonsoft as 12.0.3. In another application that references the class library, Manage Nuget Packages shows the latest stable version of Newtonsoft as 9.0.1
What would explain that difference, and how is it fixed in Visual Studio 2019? When I try to compile the application, it fails with the error that the class library's version of Newtonsoft is newer.
EDIT: I think I've found the reason: in the top right corner of the window the package source for the application was not nuget.org but Visual Studio Offline Sources.
Why is the latest stable version of Newtonsoft showing in Nuget
Package Manager as 12.0.3 in one project and as 9.0.1 in another?
When you install a nuget package, you should select the right nuget package source.
As it shows that, Visual Studio Offline Sources is your local nuget caches. It is required that you download the corresponding nuget version and then exist in this data source. So it depends on you and not all versions of the package are fully displayed.
nuget.org is the ultimate destination for developers releasing nuget packages. You can find every version of the package here. So you should check this link.
Check and enable that link.
Then, open Nuget Package Manager UI and choose nuget.org and you can find it.
We have a .net solution that contains .net standard 2.0 projects and .net framework projects.
On each build with TeamCity we have a step with NuGet Installer to restore the nuget packages for solution (nuget version 4.3.0). The step works fine, it restores the nuget packages but on Nuget Packages tab at Used Packages section we see only the nugets from .net framework projects.
Only the .net framework projects have packages.config file, the .net standard 2.0 ones doesn't have this files because nuget package manager uses PackageReference by default (as stated here https://learn.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files) so the nugets used are included in .csproj files.
What can be done in order for nuget packages for .net standard 2.0 projects show up on on Nuget Packages tab at Used Packages section ?
Thank you,
Adriana
Seems is a known issue of TeamCity, and if we need it fixed we should vote for it here: https://youtrack.jetbrains.com/issue/TW-52327
If anyone else has a workaround till is fixed please post it :)
I am working on VS2012 and have issue with installing Twilio Package via NuGet. It asks me to update NuGet Package Manager. I am concerned if updating NuGet Package Manager have effect on all the projects that are running without any issue. What are the effects of Package Manager Updates on existing projects or solution.
Coming from the Python world, I will attempt to see if I can help you here. Is the concern that a specific package will no longer be available to you if you do a global update on your NuGet package manager?
Is it possible then for you to install a specific NuGet version in a virtual machine encapsulating the project where you want to run with the Twilio package?
Otherwise, assuming all of the packages you use are regularly maintained, I'm not sure how an update to a package manager would affect them.
In my solution I have a PCL project and two other projects, each for different platforms.
Sometimes a NuGet package used in PCL require installing it to the platform project as well, otherwise things will crash at runtime.
When I install the NuGet package, how do if it's also required to install it to the platform projects?
For example, it's not clear to me if Microsoft.Net.Http requires also installation in Xamarin Android project or not. This is just an example.
Or, I don't know if SQLite.Net-PCL requires it to be installed on platform projects as well.
Things you can do:
Read the documentation provided by the NuGet package author. Either from a project web site or in the description for the NuGet package.
Use your favourite search engine for examples of how to use that NuGet package.
If there are multiple NuGet packages that are named after the platform then that gives you an idea that the PCL NuGet package might not work in the platform specific project.
Have a look inside the NuGet package using something like the NuGet Package Explorer available on Windows. If the NuGet package has lib directories that are platform specific as well as a PCL directory then it will need to be installed in the platform specific project.
Run your application and see if it works.
Taking Microsoft.Net.Http as an example. The documentation does not really say explicitly. If you search the internet you can find a blog post or two that mentions that you have to install it into your platform specific project.
If you take a look inside the Microsoft.Net.Http NuGet package you can see it has several lib directories:
There are platform specific directories, such as MonoAndroid and Xamarin.iOS10 as well as PCL directories, such as portable-net45+win8. This suggests you should install it into all your projects.
I'm looking for some experience or thoughts on the following problem.
I have a Nuget Package (EntityFrameworkExtras 1.2.0) thats hosted on the main Nuget Feed.
This package has a dependency on EntityFramework. Everything was hunky dorey until EntityFramework 6 was released.
A change in the EntityFramework code means that my package no longer works with EntityFramework 6 and onwards.
I'm trying to consider how best to deal with this problem, i foresee two options:
1) Maintain 2 versions of the Package
So, i would have one version of the package that is compiled with EntityFramework 5.0.0 and the .nuspec would
dictate that it is dependant on EntityFramework [0.0.0 - 5.0.0]
I would introduce a new package called EntityFrameworkExtras (ef6). This package would be compiled in EntityFramework 6.0.0
and the .nuspec would dictate that it is dependant on EntityFramework [6.0.0 >= *]
2) Have a new version of the current package that would support EntityFramework 6.0
so the currently version would support EntityFramework 5.0.0 and less
and i would add a new version of the package (version 2.0.0) that would depend on EntityFramework 6.0.0 [6.0.0 >= *]
I went for option 1) in the end. I believe this is an easier option for the user of the packages because its clear what each of the package's dependencies are.
I also believe its easier to use the nuget commands when working with different packages, rather then attempting to be aware that different versions of one package have different dependency versions.
Also from a development perspective it cleaner and easier to develop and fix bugs on the different packages. Finally, it would make a continuous integration environment easier to implement, because each package would be consider a different project.