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
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 downloaded a file from github(cloned it as well as downloaded it as a zip).
Here is the adress: https://github.com/bargenson/RMT .
I would like to open it to work with it and understand how the author used jsf, validation beans since I have some homework to do.
But my Netbeans (IDE 8.0.2) won't find any project in that file.
So I can't run it and debug it.
EDIT : After unzipping the file, I can't find any project to open in my IDE:
Can you guys help me understand how I can make this work?
Thanks!
The project you linked does not provide the metadata of a netbeans project¹. That means that either the original developer did use some different IDE (or no IDE at all) or that he did not choose to include said metadata into the repository.
You should be able to create a new free-form project from the build.xml within the project directory (after extracting the archive you downloaded). If you only wish to run specific code, you can also directly build the project from shell using ant.
¹ NetBeans uses a nbproject folder within each project's directory to track NetBeans-specific information, such as the mapping of the IDE's run and debug button to actual features of the project.
Try to unzip it. That should work.
For anyone having the same issue, I've finally found out that you can run this kind of project by creating a new project "with existing sources".
It worked perfectyl :)
I have a build set up and I'm struggling on how to handle one aspect.
I have successfully setup a variantdir for my project folder src build output, however I have
source that resides outside the project folder that needs to be build and included.
I am able to add the files I need into the build, however the object files are put into the external directory where the library souce files are.
Is there a standard way to solve this. I would like to avoid adding any scons files to the external directory as it is a standard intall of a tool.
What I attempted was to Mkdir() a temporary folder, Copy() the files, and build the files. This seems to work, but only the first time as the file permissions are set to readonly. Also, the only way to get it to work seemed to be to use the Execute() command which caused the action to happen at every build.
Have a look at the Repository() method (see http://scons.org/doc/production/HTML/scons-user.html#chap-repositories in the SCons UserGuide). It lets you sort of "mount" a folder to the top-level of your source tree. Then you can refer to them locally, and specifying "duplicate=1" for your variant dir should keep your remote folder clean from built files.
Hope this helps...
I was able to get the functionality I was looking for by building the objects in the external directory and then using the Move() Factory to move the object files.
If Anyone can point out a more 'scons'sy way of doing it please let me know.
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.
Using a InstallScript C# .Net Wizard to connect to a WinForms solution where I used the dependency scanner to identify project outputs.
The install package is copying the un-merged app.config file to the target directory instead of the solutions merged MyApp.exe.config file. This results in a executable that does not properly pickup configuration file settings not only because the file isn't named correctly but it also does not merge in target environment settings (ie. release, debug, etc.).
How do you have the Installer copy the merged MyApp.exe.config file to the Install Directory?
Try this, I believe this should work.
Select the config file, and in the Copy to Output Directory under File.Properties, choose Copy always or Copy if newer. You can choose any file you like with this method. Basically this file will be placed to a directory where the binaries are built. This is still a better method than configuring/fixing from InstallShield, I think. I will like to hear from you, if you disagree.
Another thing, a config file is used and determined at run-time by code. That’s probably the reason why InstallShield does not know the file dependency on it. And it is out of scope for that tool.
Have fun and let me know what happens.
Tommy Kwee
I am using SlowCheetah to do my app.config transforms and here is what we're doing to get installshield to work. For postbuild step, copy all files needed by installshield to a separate Install folder (i.e. copy "$(ProjectDir)$(OutDir)." "$(ProjectDir)bin\Install"). Point installshield to that folder to build it's output
I'm also using SlowCheetah for my config transforms, but the real answer to this question is that the InstallShield project pays attention to the selected Solution Configuration. If you select the Release configuration before building the InstallShield project, the Release output will be used in the install package.