Im building some nuget packages on our build server and have run into a problem.
I have to use nuget pack xxx.csproj to get replacement tokens to work with my nuspec file which is allright.
But when I do the nuget pack on the csproj a lot of "noise" is added to the package in form of folders etc from Open Package Convention.
Due to the fact that im using the packages with Octopus Deploy, i would like to avoid these extra folders.
Is it possible to avoid the extra OPC folders without specifying all the replacement tokens on the command line?
What's the names of these extra folders? Please open a new issue/feature request on http://nuget.codeplex.com and describe your issue in more details.
Related
I have a nuget package which has .dlls files that it automatically copies to a directory when the program is compiled. Is there a way to specify where the dlls files will be copied to?
I know it's possible to modify the .targets file of the package but assume I don't have access to the package. The project is managed through git so I'd rather not have to distribute binaries along with the licenses included in the package. Currently when someone downloads/compiles the source, the nuget package is automatically downloaded through nuget restore. Is there a way to override the .targets file of the package?
I'd prefer not to use scripts to manage the dll files if possible. Also this is for a C++ project and I know nuget has restrictions based on the languages used.
If your question is asking if there's a simple configuration file or something similar where you can write "copy contents of package X to location Y", then no.
To most people, the difference between the various components in the build system are not important, so it doesn't matter to them if NuGet copies something or their project's SDK copies something, or MSBuild copies something. However, since you're now trying to do something more advanced, these differences may be important. NuGet only writes/copies files at restore (and therefore only to the packages folder, not the project output folder), but after restore, NuGet doesn't run at all. NuGet just makes the files known to the rest of the build system, and those components are responsible for deciding what to do. For example, where to copy files.
Since both C++ and .NET projects use MSBuild, the same debugging techniques can be used. From a "developer command prompt", build your project using the -bl switch to generate a "msbuild.binlog" file. You can open this file with the MSBuild structured log viewer. You can then use the search to find where in the build each dll is copied, and what the copy arguments (including destination) is. You can also look to find where the item that defined the file to be copied was created. Then, you can write an MSBuild target in your project file (or another file that gets imported by your project file) that runs at an appropriate time and updates the item to set the destination you want the file to be copied to. But, MSBuild is a scripting language, and you said you didn't want to write a script, so you might not like this approach. And if you're not already knowledgeable about MSBuild scripting, it's probably more effort than writing a powershell script. But at least it would happen automatically as part of the build (and therefore happen when you build and debug in Visual Studio), and not be some other process that needs to be manually run.
I've searched the entire stackoverflow community but I couldn't find an answer for this...
I have a .nuspec file and I have no idea where I have to put it. Some topics say that I have to put it in the project directory and include in version control. Others say that its just keep the file in the same directory that the .nupkg file... but it doesn't worked to me. Any idea?
Thanks in advance.
A NUSpec file contains package metadata and is used to create a package.
A package is created from your project, which is why it would make sense to place the NUSpec file in the project folder.
It makes sense because it can then be committed to your source control as part of that project and this keeps everything in one place, it makes it easier to create the package automatically using your CI / CD pipeline.
You could, of course, do other things like create a NUSpec folder on the same level with your project folder and you could put your file there. Nuget.exe accepts a path to your NUSpec file so the actual location is irrelevant.
However, always consider your source control and how you manage / create this package, as long as you can do that easily, then place it wherever it makes sense to you.
You mentioned NPE, that doesn't really matter as behind the scenes it will more than likely call nuget.exe anyway. If you want to learn how to use it, have a look here : https://learn.microsoft.com/en-us/nuget/create-packages/creating-a-package.
They also recommend, as a convention, to have the nuspec file in the same location as the proj file.
As i understand from on of you comments you construct the package with the NPE.
As far as I remember the NPE was a ClickOnce application which opens up packages and you can put or even create packages there.
When the question is: Where do i put the nuspec within the package? the answer is: In the root folder of the package:
Otherwise the answer is already answered by the other answer.
Infos:
nuget packages are zip files
To get an idea where the nuspec resides in other packages just open one with NPE or 7zip
I had a look into the newtonsoft.json package
Unzipped it and it's obviously in the root folder of the package
High level overivew of the steps involved:
Use MSDeploy to create a deployment package
Edit the contents of the zip package and then repackage it
Deploy to a remote server fails as the values in the systeminfo.xml are different to what it expects i.e. the list of <installedComponentInfo> must be different from the source to the destination server. If I manually edit the xml and remove all the <installedComponentInfo> re-zip the package and try again it works fine.
So can I tell MSDeploy to ignore the systeminfo.xml file when it does the deploy step above or any other suggestions around the <installedComponentInfo>?
The error is:
Warning: Skipping source dirPath (c:\blah\blah\Package) because of rule SkipInvalidSource.
The Zip package 'c:\blah\blah\Package\MyPackage.zip' could not be loaded.
And nothing gets deployed to the remote IIS server.
I have done several searches on this so any answers on why the systeminfo.xml is causing an issue or more importantly a workaround to ignore it please?
Thanks in advance.
Try disabling the SkipInvalidSource rule.
msdeploy -verb:sync -source:webServer -dest:webServer,computerName=Server2 -disableRule:SkipInvalidSource
I am curious why you are manually editing the package. You can use MSBuild to customize the package or create a custom package yourself using MSDeploy.exe directly.
http://www.dotnetcatch.com/2016/05/19/extending-the-webdeploy-manifest/
https://technet.microsoft.com/en-us/library/dd569019(v=ws.10).aspx
I am trying to install a package (oForms) with a new Orchard 1.8 installation, but receiving the following error:
"Package installation failed: There was an error installing the requested package. This can happen if the server does not have write access to the '~/Modules' or '~/Themes' folder of the web site. If the site is running in shared hosted environement, adding write access to these folders sometimes needs to be done manually through the Hoster control panel. Once Themes and Modules have been installed, it is recommended to remove write access to these folders."
This seemed rather straightforward, however my host has confirmed permissions are fine (and even added Everyone/Full Control to the folder), so I'm lost and appears to be happening with all modules from the Gallery, not just oForms. I changed the Config/log4net.config file to log everything, and I don't see anything specific in there except where it logs the same message above. Nothing outside of that stands out at all.
Is there a way to see why this is failing? Or, if not, is there a way to get the module and install it manually? I tried to download from the gallery, but it's just a NuGet package so I'm not sure how to take that and grab the raw module files.
You can use a program like 7zip to unzip the nuget package, then copy in the module manually yourself.
As for the permissions, when adding a new permission to the folder use:
IIS AppPool\name of your application pool
I also had this exact error message when installing modules from the gallery, and it took me a while to figure out what was happening. I made new installations, copying over files one-by-one, and eventually found the culprit. For my case anyways...
For me, it was all due to a bad formatting in my custom Theme. Specifically the Theme.txt file. The line where is says Version:, I had it formatted without any "."
Good:
Version: 1.0
BAD:
Version: 1
Yes, doing this simple mistake prevented me from installing Modules.
I am coming to the conclusion that nuget is not worth all of the issues it has with source control and deployment. So how do I get rid of it? I want to go the old route of putting the referenced dlls in the bin folder and doing the configuration changes as normal.
We have a similar issue, and I can to some degree see your point - the packages folder that NuGet creates at my solution level is good in that it collates the required dependencies into a single folder for use by projects in that solution - BUT it does become a problem when our developers try to push the solution code into source control, as I don't want to store an EntityFramework.dll folder with each solution, and particularly with all of the gumph that comes with it. (Incidentally, I personally don't think that .dlls should even be committed to source control!)
But in terms of your question about getting rid of it, I'm not entirely sure how much it's woven into Visual Studio now, but here's a change you could try out:
Inside Visual Studio, go to the Tools > Options > Package Manager > Package Sources. Un-check the box that makes the 'NuGet official package source' available. This, in theory, should make the NuGet API unavailable to your IDE.
Hope this helps.
My team opted to use NuGet for discovery (we love it for that), separately from our active projects, and to manage our references through another means to achieve control and minimalism. This is how we removed NuGet from those projects:
First, uninstall the NuGet packages in your projects (optionally re-add your references without NuGet at this point, or at the end)
In the same folder as your solution file (.sln) there may be a .nuget folder, which you should delete if no other solutions in that folder rely on NuGet.
In each project folder, delete the packages.config file. If this wasn't checked in to source control, every developer needs to delete packages.config from every project in every branch that is affected.
In each project file (.csproj), there are two lines in the PropertyGroup section that should be deleted:
<SolutionDir Condition="$(SolutionDir) == '' Or $(SolutionDir) == 'Undefined'">...</SolutionDir>
<RestorePackages>true</RestorePackages>
There is also a section at the bottom of each project file (I've seen multiple incarnations at this location, so this is just an example)
<Import Project="$(SolutionDir).nuget\nuget.targets" Condition="Exists('$(SolutionDir).nuget\NuGet.targets')" />
You have to coordinate this with your team. If anyone opens a solution that includes projects with packages.config files in their directories, NuGet will undo the manual edits from above; especially if you have Auto-check turned on.