I'm using a NuGet package called Hangfire in my VS project. However I'd like to be able to step thru each Hangfire API which is not possible as these files are under the "References" folder, so I've downloaded a copy of the Hangfire source code from Github. However, how do I integrate this code into an existing Visual Studios Project? Or maybe even simpler, instead of installing a NuGet Package, how do I reference the methods in the HangFire source code in my VS Project?
In order to reference these files, you'll need to...
Add the Hangfire project (or projects!) into your Solution. This can be done by right-click -> add existing Project on the solution.
Make sure that you're referencing the Hangfire in the Solution. This can be ensured by removing all references, and then readding them, making sure to draw from the Solution section in the Add Reference dialog.
Make sure the Hangfire projects are set to build in the dependant configurations. This can be done by selecting the Configuration Manager either in Solution settings or via the configuration or platform drop-down. Make sure the Hangfire projects are checked for any configuration/platform combinationin which your projects are selected
Assuming you have a repo for you project (and you always should), you may also be able to embed Hangfire as a subrepo in your repo, so updating and keeping versions synced is easier.
Related
I have multiple projects and everything was working ok prior, but I had to download a UI framework package + change the source. I decided to include the DLL's in each project, reference them per project, and now trying to build a solution that references multiple projects blows up saying "type is in both" but I don't understand the problem. Using DLL's, shared projects, why is Visual Studio and the build so confused and can't figure out how to handle this?
The reason I used shared project references too is so I can use code & classes from one project in another and we have class libraries too.
Is there an easy way to fix this? It worked fine as a nuget package so why does using built DLL's isolated per project present a problem, it's the exact same thing.
Seemed to be related to Visual studio caching and how packages are managed so I reverted by source code to start over again. I uninstalled/re-installed nuget packages, manually added my own DLL's, re-built everything from scratch, and it finally worked.
I'm coding on a project that has several Azure-based applications, as well as several Windows services, etc. Needless to say, it's just a bunch of individual applications that are deployed out to Azure, or elsewhere, and expected are all expected to work together.
We use Nuget for our underlying library project versioning. Every feature or change results in a bump to the Nuget version, a package published to our private Nuget server, and a subsequent update to every other application that needs the update. This is currently a tedious manual task, but is not even my most immediate source of frustration.
The thing that I struggle with the most, currently, is while doing development on a feature that requires changes across the entire set of applications, from bottom to top, and having to constantly push out Nuget packages and update Nuget packages just to even develop and debug.
Prior to using Nuget, we may have just added all of these projects as direct dependencies on disk, which removes versioning but instantly lets me develop against my local changes.
Now with Nuget, I can't develop against local changes without pushing out a new package.
Is there a workflow that I'm missing that would allow me to still use Nuget but also be able to make changes and work locally without having to push and pull Nuget packages all the time?
Can I somehow develop against local projects, but also somehow have the project dependencies know to use the Nuget packages?
I ran into this issue when setting up a shared NuGet repo for my company. You can set up local a NuGet feed and 'publish' just by dropping files to a folder. This is extremely useful for local testing before you're ready to publish to the shared repo.
Also, NuGet uses semantic versioning. I find it useful to have pre-release versions by using a tag like MyLibrary.1.0.0-prerelease-12345 so you can still have incremental builds, but most other apps will not be notified of the changes until you create a major release such as MyLibrary.1.0.1. This could require you to make some changes to your DevOps process, but it allows multiple developers to test your package before 'officially' releasing it.
If your issue is that you want to be able to easily update multiple applications locally and test those changes. I have occasionally found it useful to create a single solution file encompassing all my projects so I can quickly open, update, and build everything in one Visual Studio instance. However, this solution is not particularly scalable, so you might be better off writing PowerShell scripts for automation.
Update Another solution that you might find useful is NuLink. I have never tried it so I can't actually endorse it, but it purports to provide similar functionality to npm link (and actually uses symlinks just like npm does).
Given the projects are all in the same repo, just use project references instead of package references.
When you pack a project, NuGet will convert project references into NuGet dependencies, and the dependency version will be the same as what the other project is if/when it is packed.
Check this answer, where you could:
build the dependency's code locally to produce DLLs.
replace the DLLs in your machine's nuget cache folder corresponding your dependency with the local DLLs produced in the previous step
That's a quick way to see changes locally without publish-consume cycles
We've got two sets of projects, one is framework projects and the other is the actual app. The app references the framework projects directly via the visual studio project reference feature. The framework build process publishes a nuget package already. Is there any way to make it so when I trigger a build on TFS of the actual app it uses that nuget package instead of the project reference? Ideally I'd like to have it still be a project reference when local, but if that's not possible that's alright.
I discovered you can use conditionals in the csproj files to determine which item group to use, and by making a custom build configuration I can specify which item group to use on TFS.
The setup: I've created a library targeting .Net Standard 2.0 in VS 2017 and this library uses NuGet to reference a 3rd party driver and manage its dependencies. So far, so good.
The next step is to create an application that uses the (shared) library, in this case a console app targeting .Net Core. I can, of course, add a reference to the DLL(s) that form the shared library. That compiles but doesn't run because the 3rd party stuff is missing. I could of course just copy all required DLLs to the application but for obvious reasons I'd rather use NuGet.
I'm not very experienced with NuGet, never used it in this constellation and having read articles like NuGet cross-project dependency I'm getting the impression I need to fiddle with the application's project file in order to get the library in a complete form but surely that can't be the way forward.
So my question is - is the problem on the side of the library, i.e. do I need to build or export in a particular way, or on the side of the application which, IMHO, shouldn't need to know that level of detail about some library it consumes.
Any help much appreciated!
I'm sharing a large, complicated library this way with several other solutions.
First, set up your library. Right click on the library's project name and choose Properties. About halfway down you'll see a tab labeled Packages. You can use that to auto-generate the NuGet package every time you rebuild the project. Just increment the version number. I use four position version numbering -- the first three are semver-style (major release, minor release, patch release), and the fourth one I increment manually for each new build.
I recommend creating a folder on your drive or network specifically for your local NuGet packages. You can create folders under that for each project. Then you point your debug and release build output to that project folder, and the NuGet package will be generated there, too.
Finally, back in Visual Studio, go to Tools -> Options -> NuGet Package Manager -> Package Sources and add that top-level folder as a package source.
From there it's simple -- open your NuGet dependencies in your consuming app. There's a drop-down at the top right where you can choose the package source. It will automatically search all the child folders and find whatever packages you've created. Now when you tweak your library, it's just a single click to update the client apps.
We've got about two dozen projects, which all use different NuGet-packages and a bunch of Telerik WPF libraries, the latter are usually added by GAC, which on its own does not add a hint path to the csproj-File. (Good)
As soon as we use Telerik's upgrade wizard to simultaneously upgrade the references of all projects, Telerik starts copying the files to a local lib folder next to the bin folder and adds hintpaths, which do not exist on other developers machines AND need to be discarded before pushing to Git every time. (Bad)
BTW: We regularly get the same problem (regarding hintpath) with the Spire NuGet-Package.
Now we came up with some suggestions, which we internally valued differently and therefore did not come to an accord:
Keep discarding the chunks containing the hint path
Ask Telerik to fix the wizard
Check the libraries into Git
Add Telerik libraries using their NuGet server
Create a Libaries-Path we manage by hand, maybe as a network drive
What's other peoples approach to handling those issues?
I'd go for "Check the libraries into git".
Rationale: when a developer (or CI system) checks out your project from source control, he should be able to build it right away without having to install dependencies like GAC assemblies.
You need to use NuGet for that, it's the easiest and most organized way, you should not have a problem for other developers when you install a new package as long as you are committing package.config file, in this case any one will do a build of the solution visual studio will automatically restore NuGet Package.
Make sure to set your NuGet settings as below image shows:
Don't use the Telerik wizard. Add the Telerik dependencies using NuGet. They have a private NuGet repository. See the tutorial here.