I know there is a way to do this using CLI. Is there a way to publish symbols for debugging packages in development using the NuGet Package Manager?
Asked another way, how to debug a package when the package is not able to run in a stand alone manor?
Boy...do I feel stupid! After sleeping on it it hit me.
Create a new Solution [MySolution].
Add the project [MyNuGetSolution] that is targeted toward making a NuGet package.
Add a reference to the [MyNuGetSolution] from inside [MySolution].
Develop to your hearts content! When you get the [MyNuGetSolution] to the point that you are happy then work on packaging it and using it in other solutions.
Sometimes the obvious eludes me!
Related
I have a library of nuget packages we use throughout our solutions, hosted in Azure Artifacts. These nuget packages are built with debug enabled so symbols are created and included in nuget packages.
Our projects in Visual Studio (mainly Net Core 3.1) reference these nuget packages in the normal way using Nuget Package Manager.
Each solution has SourceLink enabled so if I have any debugging requirements which require stepping into code within the referenced nuget package, I can set a breakpoint and do so quite nicely as Visual Studio downloads the sourcecode directly from Azure Artifacts.
That all works perfectly.
The issue is a productivity one. If code within the nuget package needs to be changed, I have to open the solution for the nuget package, change it, push it and wait for Azure to build. When built, I go to Nuget Package Manager, update the package, restart the app and 'hopefully' have resolved the issue. For something tricky, I can loop this process a few times which is a productivity killer.
Is there any way to debug directly in the solution for the nuget package from the solution referencing it? Or does anybody have a better process they use which is more productive?
You may try to use floating version that can resolve to the latest version in nuget. In this way, when there is updated package, your solution will load the latest version of the package during build.
<ItemGroup>
<PackageReference Include="NuGet.Packaging" Version="*" />
</ItemGroup>
Is there any way to debug directly in the solution for the nuget package from the solution referencing it?
Using project reference instead of the nuget package when you need to frequently modify and debug the source code in the nuget package.
When you consider production efficiency, please consider using project reference, when you consider portability, please try to use nuget. You could check my previous thread for detailed explanation.
For your situation, you could add the project for the nuget package to your referencing solution by the option Existing project：
Then select the project file .csproj for the nuget package.
After adding that project into your solution, you could add that project as project reference for your referencing project. Now, you could directly modify and debug the project for the nuget package.
When you finish this stage of work, you can return to the solution where the project for the nuget package is located, pack the new version of the nuget package and publish it.
I'm trying to use a SQLite database file inside my WPF application.
I tried searching for a proper library that wraps the entire SQLite library.
I found the following SQLite library which allows a perfect functionality that suites me.
The problem is building it.
I tried adding it in a Visual Studio as a project and compile it to get a dll file.
That didn't work so much well because of dependencies missing inside the project and sub-projects.
If anyone anticipated or experienced any hard time with this library, I would really use the help and of course appreciate it alot.
Thanks heads up :)
You should install it as a nuget package. Right click on your project -> Manage Nuget Packages -> find SQLite.Net-PCL. You don't need source code for this, only released package and that is exactly what nuget will download for you and add as a dependency.
You can also install the package with Visual Studio's Package Manager Console:
Install-Package SQLite.Net-PCL
If you want to have source code, this library is contained inside a single file, so you can just copy SQLite.cs to your project and it will work.
I'm creating a private NuGet package for my company and I want to distribute two different versions of my .dll. The release .dll was for some developers who can call this dll for development. And the debug .dll id for some developers to develop the dll itself for the second version.
So my question is that if I wanted to accomplish this by using only one NuGet package, is this possible? Do I have to create a script on the installation of the package that adds references in the MSBuild, or am I overcomplicating things?
Any suggestion? Thanks in advance.
Do I have to create a script on the installation of the package that adds references in the MSBuild, or am I overcomplicating things?
To my knowledge, you may overcomplicating this things. That means you want to use one dll for debug mode to test and another dll for release mode to develop, so those two dll files should be independent, which should be distributed to different packages. Because a NuGet package will normally hold just a single set of assemblies for a particular target framework. It is not really designed to ship a debug and release version.
Besides, when we publish nuget package, the release version of your dll is the best choice since users wont debug into your dll, they will only care about if it works fine and how it works.
In addition, NuGet supports use any string as a suffix to denote a pre-release version, as NuGet treats any such version as pre-release and makes no other interpretation. So you can use -beta to specify a new version of that dll for develop.
https://learn.microsoft.com/en-us/nuget/reference/package-versioning#pre-release-versions
Basically per my understanding, use a different version of the package should be better. Of course, if you persist on using one package, Nekeniehl provided the correct direction.
Hope this help you.
You can create the same dll and each team can get the dlls like yournuget -release or yournuget -debug.
I normally use a buildscript to create the nugets, paket and FAKE will help you do the job.
And here a related answer to your question:
How to create a nuget package with both release and debug dll's using nuget package explorer?
I'm trying to use R with C#. I'm using Unity and MonoDevelop on the C# side and I've R version 3.2.1. I've tried my best to follow instructions here: http://jmp75.github.io/rdotnet/getting_started/
But I'm stuck. Here's what I've done
download nuget.exe, put it in a folder already in PATH.
open CMD.exe
run nuget install R.NET.Community
If I try to reinstall R.NET.Community with the same command above, I got the message that it is already installed (which is good I guess).
My question : what now? I tried to run the RDotNet namespace, but it's not recognized. Obviously I need to set up something else, but I do not know where and what. Any lead would be appreciated!
I wouldn't expect just running the nuget install to add a reference into your project - the nuget installer is basically just downloading the package for you.
You could manually add a reference in your project to the relevant assembly file (.dll) that has been downloaded. However, it would be better to use a package manager within MonoDevelop. If you're using MonoDevelop 3.x or 4.5, you should use the NuGet MonoDevelop add-in and use that to manage the NuGet packages for your project. MonoDevelop 5.x has a NuGet package manager built in, apparently.
I have an asp.net application using EF, MVC4 and some additional packages. Whenever I try to open the project on a different PC I have issues with the installed packages. My references are marked as missing, and the code is far from compilable. Last time I solved it by deleting references and packages and installing the needed packages one by one. I find the solution tedious. Is there any better, global solution for this? How is this supposed to be done? Shouldn't this be automated?
Thanks for the help and pointers!
UPDATE
I DO use NuGet Packages, (otherwise it would be very hard to get all these dlls) but somehow I always end up with uninstalling and reinstalling the packages to make my project work. I always end up with wrong versions and not compiling code.
I end up doing the following:
Delete package.config
Delete dependencies from the web.config file
NuGet Package Manager Console:
PM> Uninstall-Package A.B.C
PM> Install-Package A.B.C
Clean - rebuild project and hope for the best
I think Uninstall - Install can be replaced with Update-Package –reinstall A.B.C
I was hoping that there is a simpler solution for this.
If using visual studio; you can enable automatic package restore; this article outlines nuget in detail.
If you go to Tools -> Options -> NuGetPackage Manager you can make sure that the auto download is enabled. See the screenshot below.
Without knowing which references are broken, I would assume that you can at least use NuGet Packages to manage Entity Framework and additional framework references.
As lucian.jp said nuget it probably the way to go. At my company, we usually will go out of our way to find and use only packages that have maintained nuget packages, and even most of the core Microsoft ones have them, for example https://www.nuget.org/packages/Microsoft.AspNet.Mvc/
For the other ones, keeping a little thirdparty folder with external assemblies/dlls in the root of your repository and then reference from your project to that instead of from some random place on your hard-drive. I.e. check the third party assemblies into your project somewhere that is not your bin directories.
So if you have an existing project, here is what I suggest you do to avoid future issues:
For each of the assemblies, including your MVC ones, find the nuget equivalent, remove the dll from your project and add it back using the nuget package manager.
Get a copy of all the remaining assemblies and create a folder in the root of your repository and place them in there, then delete all of them and add them back in referencing the dlls from that folder.
If you are using git I'd also use .gitignore to not check in your bin directories. Which will force a new deployment of your code to get the assemblies from their respective sources.
Use Nuget for DLL packages like EF and MVC. But do not use Nuget for JS / CSS packages instead go for bower. Nuget packages for CSS and JS libraries are good but just their installation and uninstallation is tricky and may not match your project structure.