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.
Related
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.
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.
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.
When I publish a ClickOnce application, one of the references that is included in one of my projects is missing.
If I go to my project's Properties -> Application Files, this missing reference is not even listed here.
My bin/Release folder has an .exe.manifest file, and I noticed it that it is also missing from here.
However, when I build the project, the DLL is in fact copied to my bin/Release folder.
How can I ensure it also deploys this required dependency?
I finally found a solution for this problem and I hope it will solve your problem to.
In my case, I'm editing an old application at work which have multiple projects, but the main project and it's back end project are the most important here.
The back end is added in the References section of the main project.
In the back end, a third party dll was imported, but this dll requires 2 other dlls.
So those 3 dlls were added in the References section of the back end project.
At that point, one of the 2 other dlls was not showing in the Application Files section for ClickOnce.
I've come up with a couple of ways of fixing it, but the most elegant one was to add this dll in the Reference section of the main project.
As stated in How to: Specify Which Files Are Published by ClickOnce, change the Copy Local property value on the reference to True.
References to assemblies (.dll files) are designated as follows when you add the reference: If Copy Local is False, it is marked by default as a prerequisite assembly (Prerequisite (Auto)) that must be present in the GAC before the application is installed. If Copy Local is True, the assembly is marked by default as an application assembly (Include (Auto)) and will be copied into the application folder at installation. A COM reference will appear in the Application Files dialog box (as an .ocx file) only if its Isolated property is set to True. By default, it will be included.
I know is this an old question, but for anybody having similar issues. I think this is a cleaner way around the problem.
I had a similar issue and everything I did to get ClickOnce to deploy with the offending .dll failed.
Eventually, I had to deploy manually.
See walk-through here.
That worked for perfectly for me. But, for the life of me, I still wonder why that process can't be added to VS (I'm using 2017 community).
Using Xcode 4.0 sometimes when I remove resources from the project they still appear in the app when I run it, both in simulator and device. I remove the resource from the Resources group by removing reference only, but afterwards also remove the actual file in Finder, and yet the resource magically appears in the app.
Doing a project clean did not help.
Xcode 4.0 has a lot of problems managing its projects' "derived data". Try opening the Organizer (Cmd-Shift-2) and clicking the Projects tab. Select your problem project in the source list, then find Delete button next to the Derived Data section near the top. Go ahead and confirm deleting the derived data, then build again (this will take longer as Xcode re-indexes your project).
Does that fix it?
A bundle (and hence also an app) is just a directory, as seen from Unix and Unix-derived tools' point of view.
My guess is that they are still in the bundle because Xcode left a copy there once, and removing the originals in the source directory does not remove the copies in the built app bundle.
If you delete the app from the build directory (or the build directory altogether), you shouldn't see them any more inside a freshly built app.