We Keep Coding

How to use Microsoft's Linguistics Analysis API?

I am trying to accomplish the ability to use Microsoft's Cognitive Service called Linguistics Analysis. The nuget package Microsoft.ProjectOxford.Linguistics does not exist, or at least I am unable to find it when I search for it.
I expect to be able to add the nuget package, however, it is not there. Has anyone tried to use it recently?

There is a NuGet package (PCL.Cognitive.LinguisticAnalysis), but it is buggy (I get errors when running AnalyzeTextAsync) and its seems it is not maintained anymore.
I suggest that you use the Client Library.
Download this repository: https://github.com/Microsoft/Cognitive-LinguisticAnalysis-Windows
Copy the ClientLibrary project to your solution
Use that ClientLibrary (you may need to update Newtonsoft.Json in this project for it to work properly)

Using TestStack.White.Uia3 with other TestStack.White packages

Currently using TestStack.White for a project, and ran across the Uia3 release on NuGet. However, can't seem to figure out if it's possible to use other packages (ex: TestStack.White.ScreenObjects) with this release, or if there are plans to release compatible builds.
The only real lead on the package is this Google Groups post detailing the package. Based on my understanding, it seems to be a drop-in replacement for the mainline TestStack.White. But documentation is a little sparse. Any suggestions would be appreciated!

Yeah the UIA3 build is a branch of the master branch so the TestStack.White.ScreenObjects should continue to work with it. The UIAComWrapper branch is the UIA3 branch and has the ScreenObjects in it. It looks like the ScreenObjects was never published as a nuget package but it should be possible to use if someone publishes it.

Is there a smart way to deal with package dependencies in NuGet?

We are developing a WPF application at work which has various "common" dependencies (Unity, Prism, etc.).
It's all fine when adding new projects and then setting up the NuGet package dependency per project but when it comes to upgrades, it's really painful as it means we have to go through each and every project, delete the old references and then refetch the latest packages from NuGet.
Today for instance, I was tasked with upgrading Prism from 5.0 to 6.0 (which has breaking changes anyway) and this meant, in addition to fixing all the namespace conflicts, etc. that I had to go through every project, delete the old references, add the new dependecies and rinse and repeat.
My question is, is there a smarter way to deal with this problem or is this the standard approach?
Many thanks in advance,
Update:
I am mostly concerned with "major" upgrades which don't show up on the package manager. Version 5.0 -> 6.0 upgrade would be treated as a major upgrade and hence, would not have an automatic update applied to it in the NuGet package manager.
I don't expect NuGet to be able to do this automatically for me since such upgrades may (and often do) include breaking changes but I would like to know if there's a way to do the major upgrades less painfully than deleting the references from the projects and the packages.config for every project and then re-adding them using NuGet. For a relatively large project, this is very time consuming and I was wondering if anyone had a better way of managing such dependencies.

If you use VS2013 like you say, you can manage ALL your NuGet packages by right-clicking on your Solution and selecting 'Manage NuGet Packages For Solution'. This brings up a dialog where you can view all packages installed for all projects in the solution and all packages that have updates available. When you do upgrade the packages, VS takes care of all the reference changes required. If the package has breaking changes, then you're still on the hook for fixing those.
Disclaimer: I've never worked on a WPF project/solution but for Web/Forms apps, NuGet packages are handled this way.

I can understand your pain because i had the similar problem like you, but there is no easy way. but certainly you need to break the process differently of your daily development and your dependency update roll-out.
for the project i worked on, I use the common repository path that shared among the solutions that you work on, and you need to delete all the solutions folder references in order to get a clean state.
For each solution you work on you need to modify the property group that point to the common target repository (i'm using relative path)
Once all the things setup, you can actually perform an update with a script(I'm using python run-time script)
you can actually look at setting up common nuget-packages-folder for reference updates for detail, but it seems like what you looking at for the automate process

I had a similar problem when trying to upgrade multiple packages with alpha channel issues in Xamarin Studio, which also does not have the niceties of VS 2015 NuGet manager. I ended up writing a very simple PowerShell script that I run multiple times a day.
#
# This script updates local ibGib NuGet packages for mobileGib Android app solution.
# For convenience in copy+paste in manager console:
# ../UpdateLocalNugetPackages.ps1
Update-Package commonGib
Update-Package ibGib
Update-Package languageGib.Biz
Etc.
I believe you could tailor your NuGet commands to fit your needs.
Also, just in case you aren't aware of it, you should definitely read the NuGet command line reference. I may be mistaken, but it sounds like your scenario is doable with the Update command.

What's the difference between a dll and nuget package?

First of all, I apologize if this is a basic question. I tried looking this up, but for some reason, I got more confused. So, I decided to ask here. Is a dll file and a nuget package the same? Are they both just being referenced in the project?

When you add features to your project via a nuget package, you're just adding files to your project. It can be javascript files (like jQuery), DLLs that your project references (like Newtonsoft JSON), or a whole bunch of things (like Entity Framework or Owin/SignalR) -- anything really.
The advantage of using the nuget package system is that it tracks it all for you. It notifies you if your added packages received an update, it removes the files and unreferences them if you take the package off your project. It handles all of that for you, so you don't have to track the files that the nuget package added, place them in special folders, make sure they get copied in your builds, all that micromanaging stuff.

From the docs, https://www.nuget.org.
"What is NuGet? NuGet is the package manager for the Microsoft
development platform including .NET. The NuGet client tools provide
the ability to produce and consume packages. The NuGet Gallery is the
central package repository used by all package authors and consumers."
A package can contain one or more dlls in addition to other assets such as config files etc.

You can add libraries via reference into your project but you would not notice when they were updated.
NuGet is a Visual Studio extension that makes it easy to pull in not only libraries but components, and most importantly their configuration into your visual studio project. It will help you manage your packages installed on your project and it will notify you when the package has new version released.
Let's say I created my own DLL, I could add my own DLL by reference. However, it won't be available in NuGet until I package and publish it first to make it available at the NuGet Package Gallery.

How to download Microsoft.Bcl.Async package

At my work place, we are not allowed to install packages from Nuget, so I am just wondering is there any place to download installer instead, so an internal packaging team can distribute it across the firm.
And is the package production ready?

Unfortunately, Microsoft.Bcl.Async is only distributed via NuGet. You would need to use the package manager to get the assemblies, though you could then just copy the assemblies manually into your system.
And is the package production ready?
Yes, it is now production ready. The BCL Team just announced that this package is now considered Stable. From their post:
Being stable means the owner of that package states that API and functionality are unlikely to change and therefore suitable for use in production.

You could just download the package from another PC (out of work) and then copy the assemblies. Of course you don't get the extra benefits from NuGet, but it's still a viable option.
EDIT Just saw that a few days ago the package was declared stable as Reed correctly indicated.