Ok. Really quick question, I'm probably just being thick.
If you right-click on a projects 'references' folder then 'Manage NuGet Packages' you can then install packages and they are automatically referenced by the project you clicked on. But then I want to add the same reference to other projects in the same solution. If you repeat previous but click on another project the only option is to uninstall the package (since it's already installed), what is the proper way to add an existing (already installed) NuGet package as a project reference? Am I to add the reference using the normal dialog and 'browse' to the dll in the packages folder? Use one method to add the first reference then another for subsequent references? That doesn't seem right.
You can use Manage NuGet packages for Solution... by:
right-clicking on solution
Tools > Library Package Manager > Manage NuGet packages for Solution
Then you can choose in which projects install package as on screenshot below:
Additionally you can add installed package to another projects in solution using the same Manage NuGet packages for Solution....
The other answer here didn't help me. Here's what I did, I don't know any other way to do it. I'm using VS 2013.
I installed the package in the Package Manager Console, e.g.
PM> Install-Package Newtonsoft.Json
In the Solution Explorer, right click references, select Add Reference
Click Browse, and navigate to the dll in the packages directory under the folder of the solution.
This adds a relative path for the reference to the project, so it should work with other people getting the code from source control into different directories.
I had the same issue. The solution posted by kristianp has worked as expected, it can be a bit cumbersome however, when dealing with lots of packages. The solution, that worked for me was just to edit the myProjectName.csproj file in the notepad, and just to copy-paste references from another project like so:
...
<ItemGroup>
<Reference Include="Microsoft.AspNet.SignalR.Core">
<HintPath>..\packages\Microsoft.AspNet.SignalR.Core.2.1.2\lib\net45\Microsoft.AspNet.SignalR.Core.dll</HintPath>
</Reference>
<Reference Include="Microsoft.AspNet.SignalR.SystemWeb">
<HintPath>..\packages\Microsoft.AspNet.SignalR.SystemWeb.2.1.2\lib\net45\Microsoft.AspNet.SignalR.SystemWeb.dll</HintPath>
</Reference>
...
Hope this helps someone. It saved me a lot of clicking :)
Nowadays I use the Package Manager Console (View->Other Windows->Package Manager Console).
Chances are all you'll ever need are the following two commands:
install-package <package-name> [-version <version-number>] [-project <project-name]
and
update-package <package-name> [-reinstall] [-version <version-number>] [-project <project-name>]
where
Parts within square brackets [ ] are optional.
'install-package' will install to the specified project, or if not specified the one selected in the 'Default Project' drop down at the top of the command window.
'update-package' will apply changes to every project unless a project is specified.
'-reinstall' means uninstall then install the package again at the same version number.
At first I thought the behaviour of these commands was a little weird, but with experience I see that they are most useful like this. Although personally I would ditch the 'Default Project' drop down entirely.
Related
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.
We recently installed NuPeek for our NuGet repository and NuPeek as symbols server.
NuGet works (above) fine. It was set up within an hour.
The Symbols Server on the other hand is a different story. Packages are pushed to NuPeek (normal packages and symbol packages). I see on the server that both are picked up and placed in the correct folder (source files too, .cs in this case).
I have set up Visual Studio so it can find the correct symbols server. When I create a new project, install the package (that also has a symbols package), use the code from that package and try to debug it, the following happens:
In the cache folder the "package" is downloaded
The cache folder also has a src folder. Within a source folder which has a folder with the same name as the package -> version.
The version folder is empty
The folder cache/ packagename.pdb/guid/ packagename.pdb is present
Still, Visual Studio cannot find the correct CS file to show. After some digging in the NuPeek server folders I noticed the folder symbolsPath -> temp -> PackageName -> lib -> net45 is empty, while the symbols.nupkg clearly has sources (one cs-file to be excact).
I had this working before, but we switched servers (Azure website to Azure CloudService), but I'm 99% sure this is not the problem.
Am I missing something? Does anyone has any clue?
Thanks in advance!
Does anyone has any clue?
If anyone does then the author of the project, Jérémie Chassaing, would be the most likely candidate. Don't hesitate to add an issue to the issue tracker. Not much there right now and he looks pretty responsive so worth your time.
Do run through the setup checklist first:
Tools + Options, Debugging, Symbols, add http://myserver/NuPeek/symbols to the Symbol file locations list. Ensure that you have a valid Cache symbols directory selected
Tools + Options, Debugging, General, tick the "Enable source server support" option
Untick the "Enable Just My Code" option.
Tick the "Print source server diagnostics" option. Update your question with what you see in the Output window so we'll have a better shot at figuring out the real problem
Ok, this is an old question but as i found the solution today i'll post it here.
This is probably because you instaled NuPeek too deep in your website structure.
A bug in Nupeek requires that it is installed at the root level of your site (for ex: www.domain.com, and not www.domain.com/Nupeek/).
Else you can fix the bug in SymbolTools.cs, replace the SourceBaseUri getter code by this :
private static string SourceBaseUri
{
get
{
var httpRequest = HttpContext.Current.Request;
var applicationUri = new Uri(new Uri(httpRequest.Url.GetLeftPart(UriPartial.Scheme | UriPartial.Authority)), Path.Combine(httpRequest.ApplicationPath, "source"));
return applicationUri.ToString();
}
}
Hope this helps.
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.
In trying to figure out the solution (no pun intended) to this problem: How can I get my Web API app to run again after upgrading to MVC 5 and Web API 2?, I realized that I have sort of brushed aside the relationship between packages and referenced assemblies (haven't given them much thought).
So what is the relationship? I manage packages with NuGet, and I manage assemblies via the context menu beneath the project's References folder, but I see on closer inspection that there seems to be a 1:1 correspondence between some of them.
e.g., I have Entity Framework in my NuGet Package Manager for my project, and I also have an assembly reference to EntityFramework. Yet this is correspondency does not extend across the board.
After all, after selecting the context menu item (I don't know if it's from Visual Studio or Resharper) "Remove Unused References," I have 14 Items referenced; but in the NuGet Package Manager, I have 30 packages listed in the "Installed Packages | All" tableau.
Yet, they all sport a "Manage" button when I highlight them; it seems that in other projects they say "Installed" with a green check mark or something...???
A package consists of 1 or more assemblies. It can also contain other non-assembly (aka, non-dll files), but that's the simple way to look at them.
When you add a "package" to your visual studio project, a few things happen.
Some xml is created saying "This package is a part of this project (csproj for example).
The 1 or more assemblies needed for the package are downloaded locally.
The necessary references are added to your project (csproj for example). This logic is written inside the nuget package. This mimics you doing a "right-click/add reference".
Other things might happen, but the above is the simple version.
A good/quick way to learn about packages is to
Get the MyPackage.nupkg file.
Rename the extension....from ".nupkg" to ".zip".
And look around the .zip file contents.
You'll see folders like
.\content
.\lib
.\lib\net20
.\lib\net40
and look for some .ps1 files.......and that'll show some voodoo sometimes as well.
That's the simple version. But it'll get you off the ground.
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.