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.
Related
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 am in the process of porting a complex set of reports from iText5 to iText7 and need to rebuild the .Net community edition with Debug symbols to complete the port from 5 to 7. I am able to run the "possibly" correct CLI command this way:
dotnet pack iTextCore.netstandard.sln /p:Configuration=Debug
but that doesn't get me the same package structure you build for the official nuget package.
We will of course pay for the commercial license when we know our code runs, but in the meantime I'm trying to convert old code.
What is the official guidance from iText Software on how developers should accomplish the port from 5 to 7 with your existing resources? Is there a way to get a Debug build with symbols.
Best regards and congrats on building an excellent library.
TL; DR: use this repository and run
dotnet build iTextCore.netstandard.with.svg.sln /p:Configuration=Debug
nuget pack itext7.nuspec
There is no official guidance on how to migrate from iText5 from iText7. This is a major update of the library and almost all of the user-facing code was developed from scratch. Coming up with such a guide is absolutely infeasible because there is too much to cover. One source of information would be to compare samples from iText in Action book which covered a lot of use cases for iText5 library to their versions ported to iText7. The latter ones can be found here. But if you have specific questions feel free to post them on StackOverflow and you will probably get your answers (if those questions haven't been answered yet; many have been already).
The way the official NuGet package is assembled is more difficult than the one you guessed, but only a tiny bit.
If you look at the repository layout, you will find itext7.nuspec file which is a complete descriptor of the final package. To pack everything you need to call
nuget pack itext7.nuspec
However, you need to build the binaries to pack first. You are interested in iTextCore.netstandard.with.svg.sln solution file which integrates all the Core modules at the moment. The command would be similar to what you described:
dotnet build iTextCore.netstandard.with.svg.sln /p:Configuration=Debug
Please note, however, that an easier approach in order to enable debugging might be for you to download the source code and reference the projects directly, thus you would be easily able to walk through the source code, possibly do the modifications etc.
It is my first time to use nuget.
I fork a github project, applied my own changes. How do I let Nuget pull my source code, not origin one?
Thanks
What you are asking is to take over someone else's project, for obvious reasons that is not allowed. You must be invited:
https://blog.nuget.org/20130205/managing-package-owners.html
If the GitHub project has been abandoned and the owner is not responding. What you can do is contact github support ask them to detach your fork, then rename the project and create your own Nuget package.
I will strongly recommend AppVeyor it is free for OpenSource projects and very easy to configure, it can build your project run your UnitTest and deploy to Nuget or to Myget
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.
I recently added MathNet.Numerics through NuGet to my C# solution. The package directory in the solution folder ballooned to about 50 MB! Yet I can simply download the MathNet dll and use only that, which takes up only 1.5 MB. If I want documentation as well, I can include the XML, which is another 3.5 MB.
Am I using Nuget wrong or is this expected behavior? It seems like it is wasting a lot of space.
The reason the package contains that many editions of the same version is a conflict of interests:
We would like to support a wide range of platforms.
We would like to leverage advanced features even if they are only available on some of the platforms (usually only on the full .Net framework, like TPL or System.Numerics), for performance but also for compatibility and usability reasons.
Avoid downstream dependency nightmares by only publishing a single package per version, including all platforms.
If this is causing you problems, consider to bring this point up with the team in discuss.mathdotnet.com (new) or maybe open an issue in GitHub.
PS: If NuGet doesn't work well for you, we also provide Zip archives you can handle manually and pick exactly what you need.
It looks like expected behaviour. It is up to the NuGet package owner to decide how many versions to put in a single package.
You can probably safely delete it, but it'll come back every time you restore the NuGet files. If you are worried about a lot of bloat being included in your build or release, check your .csproj file and make sure you only copy over the MathNet.Numerics.dll version you need.