Does WinRT development support NuGet packages? - nuget

Can we use NuGet packages in developing WinRT Metro style applications using XAML/C# or HTML/JS/CSS?

NuGet currently supports WinRT libraries for deployment in your project for .NET 4.5 -- we're working with the team to get greater support there as well.

Here is a 2 parts articles on how integrate Nuget Dev with WinRT component :
http://blogs.msdn.com/b/mim/archive/2013/08/27/packaging-a-windows-store-apps-component-with-nuget-part-1.aspx
http://blogs.msdn.com/b/mim/archive/2013/09/02/packaging-a-windows-store-apps-component-with-nuget-part-2.aspx
I Hope this could help you !
Sebastien

Related

how to install Microsoft.Azure.DocumentDB.Core on portable library

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

List nuget dependencies and their current versions

I have large, complicated solution with dependencies on many nuget packages. I want to find out the current versions of all my nuget dependencies.
At present i have a console application that looks through the source tree, finds all the packages.config files, extracts the relevant information and dumps it to a file. Does nuget have a built in way of doing this?
NuGet provides a Get-Package command you can run from the Package Manager Console. It will list the packages and versions that are in the current solution. Example output is shown below:
PM> Get-Package
Id Version Description/Release Notes
-- ------- -------------------------
CommonServiceLocator 1.3 The Common Service Locator library contains a shared interface for service l...
MvvmLight 5.2.0.0 The MVVM Light Toolkit is a set of components helping people to get started ...
MvvmLightLibs 5.2.0.0 The MVVM Light Toolkit is a set of components helping people to get started ...
Newtonsoft.Json 7.0.1 Json.NET is a popular high-performance JSON framework for .NET
Xamarin.Forms 1.3.3.6323 Build native UIs for iOS, Android, and Windows Phone from a single, shared C...
Xamarin.Forms 1.4.4.6392 Build native UIs for iOS, Android, and Windows Phone from a single, shared C...
Xamarin.Insights 1.10.6 Insights for your Apps
Note that this requires the NuGet packages to have been restored. The Get-Package command basically looks at the packages directory to find the used NuGet packages. It does not use the packages.config file.

How to enable nuget on Artifactory without using Pro features?

I just started using Artifactory for my pet project and I want to configure it to support nuget. I know that Artifactory Pro supports nuget but I am curious if it's possible to do that without using Pro.
It is not possible. You might consider applying for an account in oss.jfrog.org (if your project is popular and open-source).

AutofacContrib.Multitenant.dll Vs Autofac.Extras.Multitenant.dll

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.

Best strategy to target .NET 4 from a NuGet package with a portable class library

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.