We're creating a global architecture for all products of our company, and we've come to have a very specific file-system structure in which packages folder should not be in the root of solutions directory.
Of course we can reference EF dll files from somewhere else, because it's configuration is done in csproj file.
However, when we delete packages folder, add-migration breaks, because it depends on the tools existing in the tools folder.
Is it possible to add paths to Nuget package management console? or is it possible to use add-migrations out of PMC, or do we have any other choice?
Based on our experience we think it should be possible, but we can't find out how.
Related
I am working on a .Net application and planning to use SQLite as its back end.
I ended up with “Not able to load SQLite.Interop.DLL”
Then I found the documentation in http://system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki
But I’m not able to find a zip that contains all the essential files mentioned in the above documentation. All the files are either separated or in NuGet packages.
Can someone help me out to find a zip the contains the following DLL files as a zip in a single zip ?
<bin>\System.Data.SQLite.dll
<bin>\System.Data.SQLite.Linq.dll
<bin>\System.Data.SQLite.EF6.dll
<bin>\x86\SQLite.Interop.dll
<bin>\x64\SQLite.Interop.dll
I don’t want to reference a NuGet package with my project, as I’m building this application using ANT and signing this is a separate build server that I’ve setup to compile and check the MSI files and it’s generation.
I’ll add a copytask to my ant build and copy all the dll files to the project before building it into msi. The only thing missing is a zip that contains all these above essential files.
PS : I need this application to work on both x86 x64 arch.
I've Searched around almost many sites and like #Blindy and #Selvin said there is no way around NuGet packages it seems.
Hence, I've downloaded the NuGet package from http://system.data.sqlite.org/downloads/1.0.113.0/System.Data.SQLite.Core.1.0.113.0.nupkg here which seems to contain SQLite as well as Platform Interop files.
Once I've downloaded these,
In VS, Tools -> Options -> NuGet Package Manager -> Package Source -> Added a new source as my local folder.
I've placed the downloaded package inside this folder
Project -> Right Click -> Manage NuGet packages -> Under the browser tab, I've selected the RHS filter as the source I've added in the previous step and the package I've downloaded was listed under here.
I Installed them and this created a packages folder inside my solution directory.
Then I was able to use System.Data.SQLite in my application. But it still threw "Could not load SQLite.Interop.dll". To tell the builder that you have to use the interop files, open the csproj file for the project and add,
<ContentSQLiteInteropFiles>true</ContentSQLiteInteropFiles>
And then this started working properly. I might use this as a structure instead of running a copytask in ant I guess.
Thanks to #Selvin and #Blindy
I am still confused about how nuget works. I git clone a C# .sln project and from console, and I ran this nuget command:
nuget restore my_project.sln
it came to my attention that it generates two packages containing all dependencies required by my_project.
One package is located under my_project/src/packages, the other c:/users/my_user_name/.nuget/packages. While the file structures are a little different the DLL files in both packages are identical.
That confused me. Why two packages are generated by default? Where exactly does Visual studio look up for the project's dependencies?
More important, which config file should I update in order to only keep a copy of the dependencies and how can I specify the location in my file system for the packages?
Recent versions of NuGet support package references in project files.
This format will restore packages on demand, using your %USERPROFILE%.nuget folder as a cache. And your solution folder won't be "polluted" by a packages folder with binaries that you probably don't want to commit to source control.
VS2017 allows you to select "PackageReferences" or the older "Packages.Config" format when you create new projects (Tools/Options/NuGetPackageManager/General).
You probably have some projects in your solution that use the older "Packages.config" format, which stores in the packages folder in the solution directory, and newer "PackageReferences" format.
To convert the older projects to the new format, I believe you need to remove all packages from the project, then add them back again. They will be added using the default format you selected, with a prompt for confirmation if you selected "Allow format selection on first package install".
I have several WCF and WebAPI services as well as MVC websites in a visual studio solution. Currently, we are creating WebDeploy packages for these services and websites to deploy to IIS. I'm starting to look into Octopus Deploy for deploying our services and websites instead of WebDeploy. However, Octopus Deploy uses Nuget packages to deploy.
I'm trying to figure out how I can easily create a Nuget package that contains all the files that would normally be published into a WebDeploy package. This may not be all files in the project directory or the bin directory. I found this blog post describing how to package a csproj into a Nuget package during the build, but I found that the resulting package didn't contain any of my dependency dll's. I realize I could write a nuspec for each of these projects manually and include exactly the files I want, but I'm looking for a more automatic way as this would create more maintenance when my project changes.
Does anyone out there know a good way to generate a nuspec or Nuget package that contains only the files needed to run the application, similar to the way publishing to a WebDeploy package only includes the files it needs?
Octopus Deploy has a CLI called "Octo.exe" that can package up your application into a NUPKG.
You will need to install Octopus Tools which you can download from https://octopus.com/downloads
Please see http://docs.octopusdeploy.com/display/OD/Using+Octo.exe for the documentation and how to use it.
A good example to use Octo.exe is part of a Continuous Integration pipeline when the build has successfully passed you call it to package the application and send it to the Octopus server.
After some playing around with Visual Studio, MSBuild, and TeamCity, I discovered a method that works for me. My issues was that I did not want to package up all the files in my project directory, only those that are necessary to run the application. WebDeploy handles this quite nicely as one of the options when publishing. I already have settings in my csproj file that will create a WebDeploy package on build, but this is a zip file and I don't want the zip file in my Nuget package.
I found 2 ways to deal with this:
In TeamCity, I set up a new Build Configuration that will package any nuspec files I have and publish the resulting Nuget packages to my Octopus Deploy Nuget feed. I figured out that I can use the existing WebDeploy package that gets created by my CI build configuration as an artifact dependency and TeamCity can actually unpack the zip file when grabbing the artifacts as part of that dependency. Then my nuspec file references the entire folder structure that was extracted from the zip file and packages it into a Nupak.
I was able to modify my csproj settings to use a specific publish profile I generated in Visual Studio that would perform a WebDeploy package to file system. This would result in the same folder structure as is in the zip file from #1, but simply copied to a directory. Then my Nuget build configuration could simply grab those dependencies and package them the same way as in #1.
I decided to go with option #1 as it would require minimal changes to my existing csproj and CI build configuration, and it would not break our current method of deploying using WebDeploy.
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.
We have 1 solution that contains all of our shared assemblies. Currently we are referencing these assemblies based on relative path (../../../../../SharedSolution/bin). It would be nice to create a nuget package (or a few based on various dependencies) to reference these assemblies so I can get easily update and I don't have to worry about having the exact same directory structure as everyone else on the team and all the other benefits of nuget.
However, let's say that when I'm working in my ProjectASolution, I realize that I need to make a change or add a shared class to SharedSolution. In my ProjectASolution if I have referenced the assemblies from SharedSolution with a nuget package, but I want to test my changes to SharedSolution before committing them, is the only way to copy the assemblies from the SharedSolution bin to ProjectASolution's packages folder?
Since we are frequently editing classes in SharedSolution, I'm beginning to think that nuget might not be the right way to share these assemblies.
Another possible solution is to add the projects from SharedSolution as links to any of my ProjectSolutions that need to reference them. Is this a better alternative?
Is there a better way to share these assemblies than relative path? Is there an easy way to test changes made on a dev machine to a nuget package?
You can build a pre-release package. Only developers who set their nuget to use pre-release packages will see them, everyone else will be still using the latest stable.
A good explanation and How-To can be found on the NuGet Pre-Release Package page.
To address the questions you raised in your comment:
You can build nuget packages locally, based on the .nuspec file which is usually next to the .nupkg file in the packages folder. You can use NuGet Package Explorer to do so in a GUI.
To distribute them, you can store the pre-release packages on a network folder. Any developer interested in the pre-release package can add this network folder to their nuget sources and can then use the Visual Studio-integrated nuget as usual. Or you can just copy them the .nupkg file.
You should be using as much self-contained testing as possible for an assembly before publishing a new package. Ideally, anything you would be putting into a NuGet package would be fully covered by unit tests and, if necessary, some kind of test app.
Also, if you're going to use NuGet, I would look at splitting up some of those assemblies if possible. It's easier to maintain references and track real updates to packages if they're in logically separated sets rather than one mega package.