So I have a C# application that I am developing in Visual Studio. I am using a NuGet which was really easy to install. Newtonsoft JSON. I just had a quick question because I am new to windows development.
I know to use somethings in your project you need to add the dll or lib to your installer as well, in order for the project to use that library. Is this the same case for a NuGet? Do I need to add Newtonsoft JSON to my installer?
Im using Visual Studio 2015 if that matters.
Was going to just comment but can't yet.
In general, adding a package to a project through Nuget takes care of all the necessary referencing.
Also, if you look in your reference list in the project, and right-click on the assembly in question (in this case Newtonsoft.JSON), and go to its Properties, you will see an option "Copy Local".
If this is set to true, as the description says, "the reference will be copied to the output directory".
So, wherever your .exe/.dll/lib is output, there should also be a copy of Newtonsoft.JSON in there as well.
Edit:
As your question is quite confusing, the best I can say is that if you add a package through Nuget, it will NOT be built into your application, it will still be a separate DLL file that DOES need to be included in your installers list of included files.
You don't need to install nuget package to you installshield project.
You need need to include reference in you install project to your dependency.
It will depend on the installer you use. Some will let you select the folder and will detect it automaticly, some don't.
Related
I want to write that C# code convert-nunit-3-nunit-2-results-xml-file, but despite the added nuget package i'm missing the dll in my project.
I see it in the tool's directory of the package cache, but missing it in my project.
What do i overlook?
My project is at present for .Net Core 2.1. Is my issue therefore related to this: Add support for net standard ?
I'm new to .net and don't understand all the differences so far.
As zivkan explained, the package is a tool. In fact, it's an extension to another tool, the NUnit engine package. The NUnit engine knows how to find and use the extension.
NUnit does not publish a package that is intended for use by your code as a library, because we would then have to support it as a library in addition to it's use as an extension to NUnit.
However, NUnit's MIT license allows you to use the source code, which you can find at https://github.com/nunit/nunit-v2-result-writer
Since the code has not yet been ported to .NET Core, you would have to do that yourself.
You didn't overlook anything. Not all NuGet packages are libraries.
NuGet has conventions on how files must be packed in order to use various features. For example, files in the content or contentFiles get copied into the project directory, or build output, depending if the project using the package uses packages.config, or PackageReference. If the package author wants to give you a library that you can use in your code, they must put the library in the lib directory in the nupkg (technically it could be in ref, but those don't get copied to build/publish output, they're only used at build time). The tools directory is, unsurprisingly, intended for tools packages. It's often used by unit test runners, or in this case, a report generator.
So, since the package puts the dlls in the tools directory, this means the package author intends the package to be a tool to assist you during development, but not as a library for you to use in your code. You could try contacting the package author to see if they have published another package with the same dll, this time in the lib directory, so that you can use it your project.
Otherwise you'll need to find a solution that doesn't rely on NuGet bringing you this dll as a library. One option is to have a packages.config file that extracts the package in a solution packages directory, and then you use a dll reference to the dll. Your build script would then need to first restore the packages.config file before building your project. Another option is to check in the dll into your source control management tool, if the dll's license allows that, and again have a dll reference to it.
The setup is like this:
A Xamarin.Android application, which depends on Android class library
(at least that's what the template is called in VS)
Said class
library, the purpose of which (not entirely relevant, but FYI) is
interfacing with a REST service and has a dependance on the famous
Newtonsoft.Json NuGet package.
An NUnit test project for said
library.
IDE is Visual Studio 2017, latest version.
If you build and deploy the app on the phone, everything is fine.
However, if you try to run tests from the tests project, it says that it can't find the Newtonsoft library.
I've even managed to find a sort of reason: when the library gets built, it's dependancies aren't packed inside, and they are not copied to build directory.
When .apk is built for the phone, the dependancies ARE getting packed inside.
However, when NUnit project builds itself, it only takes the library, and the dependancies are nowhere to be found.
However, there's no interface to control the behaviour of NuGet "Package Reference" type dependencies (blue ones), the properties window is empty for them. And I found no way to add NuGet packages to this kind of project as a ".config" type of dependancy (grey one).
There is a workaround - you can add the Newtonsoft package to the NUnit test project, then it gets copied to the build directory and the Android library works with it, however it doesn't feel right to me. Tests don't need that reference and it has no business in that project.
How to control NuGet packages in Android Class Library?
Your workaround is the correct solution, you don't need to worry too much about it.
That is because the Newtonsoft package is not used directly in your NUnit test project, so Visual Studio / MSBuild doesn't know if your test project needs this Newtonsoft library. In order to avoid reference pollution in NUnit test project, Visual Studio / MSBuild tries to only bring references over into NUnit test project that it detects as being required by project Xamarin.Android application.
So, to resolve this issue, we often add Newtonsoft to the test project or give a copy task to copy it to the test project.
See This Thread for some more details.
Looking for an answer to another question I now found info that my described behaviour is a known problem, described by .NET developers here:
https://github.com/dotnet/standard/issues/481
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 have used .Net Reactor to obfuscate code. Now how do I create create setup package for the obfuscated code. Or are there any other tool for creating setup package for obfuscated code.
Thanks in advance.
Not sure why this is a problem. Why don't you create the setup package before obfuscating the assemblies?
I had no problem with BitHelmet Obfuscator. My setup package just uses the obfuscated assemblies in BitHelmet's output folder, instead of project output.
Works fine.
Are you using the VS included setup project? For that, the obfuscator needs to support MSBuild based obfuscation, so that the obfuscation takes place as part of build process. This way, the obfuscated dlls are available for the setup project.
I found a way to do with Dotfuscator. Below are the steps.
You need to create Dotfuscator project first, i.e right click on solution->add project->select Dotfuscator as project type. To the project created right click on Input-> map to project output from your actual project. Build the Dotfuscator project. Next add the setup project. Point setup project output to that of Dotfuscator. And now build to create the setup. Now your code is obfuscated.
Now I am looking for a solution to work with .Net Reactor, obfuscation and add the output to setup package.
You can use the .NET Reactor VS Add-in in to automatically obfuscate the assemblies. This way your setup package will include the obfuscated files.
The solution is described here: Solution