I have a library that I want to put ChromeDriver and IEDriver in so I don't have to reference those executables from each of my different testing frameworks. I have run into an issue, though, where my testing framework is looking for the drivers in the frameworks solution directory, when they exist within the library that I'm referencing. How do I solve this? Am I even going about it the right way?
Pull down the intended package through NuGet. Then Right click on on the test project>add existing>navigate to the package directory(ie chrome) and add as shown as follows.
See the screencast
Related
I'm currently working on a console game and I would like to play sounds sometimes.
After a bit of research I found that I need to use System. Media. SoundPlayer class, but unable to find the System. Media namespace. I've reached several Stack Of questions, but they were inefficient in my case.
I might notice you that I've got an error while attempting manual package addition:
Unable to find an instance of Microsoft. VisualStudio.Shell.Interop.IVsReferenceManager
so I might not be able to add it manually.
I could not find a package called System. Media via VS nuget Package Explorer.
If someone could help me, I'll be highly thankful
to gain access to System.Media namespace, you'll need to install System.Windows.Extensions nuget package as #bolkay suggested. This require >=3.0 version of .net core.
In a project/solution with lots of <PackageReference> dependencies, it can be difficult to find the source of a transitive dependency that's being pulled in. For example, no projects in my solution directly reference the package System.Data.SqlClient, but something is pulling it in transitively. Tracking that down "by hand" is virtually impossible in a large solution or project with lots of direct package references.
Is there any ready-made way (eg, a combination of .Net CLI commands) that, given a particular package, will find and reveal the source of the transitive reference? I use Rider, which has some awesome code navigation and "discovery"-type tools, but I can't find anything that helps with my goal.
Note: I also have VisualStudio if it has this capability built-in somewhere, I'd just need a pointer to where/how.
The capability is built into the latest Visual Studio 2019.
With Visual Studio 2019, Update 6, I can see something like the following:
Note that you can also discover packages by searching in the solution explorer.
Unfortunately it's not available in the NuGet Package Manager installed view yet.
Searching in VS did not work for me, at least not for a BCL package like System.Net.Http. What did work is looking in obj\project.assets.json, which lists all dependencies.
It's still a somewhat manual process of searching for each package up the tree. https://www.jerriepelser.com/blog/analyze-dotnet-project-dependencies-part-2/ describes the process well and provides code to automate it, but I have not tried the code.
Since I had the same problem and didn't find anything working (on SO, google and my installed VS2022 Ultimate), I've create a powershell and python script.
The script uses the nuget-deps-tree - npm package to get a dependency tree and then traverses this tree to find the nuget.
See: https://github.com/Kraego/NailDownNuget
Not an ideal solution in many cases but just to mention it. Switching to paket dependency manager could help as well, especially for bigger projects.
It has a command called paket why that quickly tells you for each package whether it's a top level, a direct or a transient dependency and additionally shows the dependency chain. See this blog post for some examples.
I'm looking for a simple way to manage NuGet packages for the whole solution, to prevent conflicts between transitive NuGet packages when assembling all files into one installer.
When building a project all direct and indirect dependencies are analyzed and the NuGet resolution picks up the best matching version for each NuGet that is at least the same version as the lowest version and might also create binding redirects if necessary. (all good and fine)
The problem we have lately encountered was when we build the whole solution (200+ projects) at once, the resulting NuGet versions between all top level projects might not be identical. And due to the fact, that all resulting DLL and EXE files are installed into the same program files folder, the application can and will crash at runtime due to version mismatches when loading assemblies.
To better understand this issue I've created this sample repo.
The dependency graph looks like this:
Library1
Microsoft.IdentityModel.Tokens-5.2.1
Executable1
System.IdentityModel.Tokens.Jwt-5.3.0 (transitive reference: Microsoft.IdentityModel.Tokens-5.3.0)
Library1
results in: Microsoft.IdentityModel.Tokens-5.3.0
Executable2
Microsoft.IdentityModel.Tokens-5.2.1
results in: Microsoft.IdentityModel.Tokens-5.2.1
To demonstrate the problem, all projects compile to the same bin folder. When the whole solution is compiled and Executable2 is started, the application crashes, since the application expects Microsoft.IdentityModel.Tokens in version 5.2.1 but the actual version is 5.3.0.
For this constructed sample it is easy to find the problem and fix it with updating the Microsoft.IdentityModel.Tokens NuGet to the same version. (Manually, since Visual Studio Package Manager does not recognize this conflict in the consolidate tab).
But at a much greater scale it is far more complex to find those mismatches.
What we have found so far
Centrally managing NuGet package versions
Since it is not yet available, it cannot be used to solve the issue here.
Microsoft.Build.CentralPackageVersions
Unfortunately there is no IDE support for it, which makes managing NuGet packages very uncomfortable, which I would like to avoid if possible.
So my question is what is the best approach to avoid NuGet version conflicts between projects within the same solution?
We've experienced the same problem with some of our projects. We've been using Paket package manager since a couple of years and this has resolved that issue for us.
In short: you define on your solution level which packages you want to use in a file called 'paket.dependencies'. You can be very specific about versions, or let packet use the latest greatest. Then you can specify per project which NuGet package you want to use within that project in a 'paket.references' file. As the name implies, you reference to a package in the paket.dependencies file.
This will make sure, all references packages in your project will use the same package version. I hope this suits your needs as well.
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)
I'm looking to work on an application, an internal toolbelt if you will.
Rather than having users messing around with DLL's for the differing tools (they plug in via MEF) I was wondering if it's possible to jump on the back of Nuget?
I'd build the tools, package them as nuget packages and host them internally and the toolbelt application would then query the catalog, retrieve and extract etc etc.
Does anybody know of a way this is possible?
Chocolatey uses nuget as an underlying package manager to install applications on your pc.
http://chocolatey.org/
So I'm sure it's possible, but I've not done it myself.
The nuget documentation discusses a command line and power shell reference: http://docs.nuget.org/
Also linqpad, does something similar (in the paid for version), where you can include dll's from nuget. There is a screen shot on this page: http://www.linqpad.net/purchase.aspx