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.
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 was thinking about making a simple youtube downloading program in C# Forms. I found this library and decided to use it, although I am having some trouble importing it into my project.
I tried googling "how to import libraries to visual studio c#" but I only found c++ tutorials and the only C# I could find were outdated.
I downloaded the .zip file from github but there was no files which the VS importer could use.
I am sorry if this question is simple, but I started using Visual Studio yesterday.
You can use NuGet to import that library:
Install-Package VideoLibrary -Version 2.0.3
More info: https://learn.microsoft.com/en-us/nuget/quickstart/install-and-use-a-package-in-visual-studio
The easiest way to incorporate libraries into your projects with Visual Studio is as NuGet Packages. Nuget packages are essentially just zip files containing the libraries themselves, meta-data, stuff to help with debugging and potentially other stuff the library might need.
Many projects hosted on GitHub will have a Nuget Package available. Visual Studio will be already set up to search for packages from the most common sources, such as Nuget.org , but sometimes you may need to add an additional package source a.k.a. "feed" to your solution. This can be done by adding a Nuget.config file in your solution directory. More info on that here.
In Visual Studio there are multiple ways to interact with Nuget. You can use Nuget packet manager GUI, which can be accessed by right-clicking on your Project or Solution in the Solution Explorer and clicking Manage NugGet Packages, or you can use the command line interface through PowerShell or the Package Manager Console in Visual Studio.
I have a project with some protobuf files. I want to compile these files to C# as a pre-build step.
So I add Grpc.Tools as a NuGet package to the project. And lo and behold, the tools are downloaded inside the solution's packages folder: packages/Grpc.Tools.1.6.1/windows_x86/protoc.exe.
Our CI server, on the other hand, uses a linux docker container (microsoft/dotnet). Is there a portable way to specify where to find the protoc compiler? Preferrably I would like to just ask the system: dotnet where Grpc.Tools or something.
I had a similar issue, in my case I wanted to pack C# code using ExcelDNA tools that come with the package. The post build event was added as part of the package install, but depended on the package folder been located in the solution folder, as you say. Porting the code to Net Standard we realised that the new version of nuget cannot deal with this specific issue of post build events which require the package tools to be in some folder relative to the solution or project. So to directly answer your question see here.
However you may not find that very useful if you want to do a post build event from the solution? If you are using jenkins et al and have a seperate step for packaging then the above should work fine.
There are a couple of ways around it. Most simply you can add the tools to source control, and then manually edit the post-build events. Depending on how you feel about that.
Secondly you can force nuget to resotre the packages locally and not in the system wide cache folder. You can do this through the Nuget.Config file. I have not got the specifics to hand, but if you cannot figure it out I can look in my old code.
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.