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.
Related
I am making changes to a web forms application in visual studio 2012 and part of that change is to remove reference to an old dll. The dll is responsible for handling authentication and I have written a new class library to handle this.
My problem is everytime I build my website in the solution, it always generates this old dll. I've annotated out all references to it in the entire application and it's not in the project dependencies of the solution.
If I exclude the unwanted dll, it just generates a new one. I am completely baffled by this. It's something I've not encountered before so I am not sure what else I can do.
I'm not sure what to post so if anyone can help then that would be great.
I had a similar problem (but it was with a persistent DB file being generated). I ended up having to go through the bin from the project file and editing it from there. Some files are 'hidden' from the project, and are either visible by
Make sure you are showing all files. There is a button at the top of
the Solution Explorer called "Show All Files". To see this button,
make sure that your project is selected in the solution explorer.
or by manually going through your project files.
EDIT
It can sometimes be hidden in the Global Assembly Cache (GAC) where it can reside indefinitely. http://msdn.microsoft.com/en-us/library/zykhfde0.aspx explains how to remove it (if it is indeed hiding there).
try this, remove the old project from your Solution.
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.
I have a larger solution that I desire to distribute via ClickOnce. It consists of one main shell executable that directly references only a small subsection of libraries and processes that constitute the solution.
The solution consists of a few other processes and several libraries (some C++). I need to be able to include all of these libraries and processes in one ClickOnce distribution for both local builds and TFS server builds.
I cannot reference every other library and process form the shell project. And I do not wish to push these files into a MSI to be treated as a prerequisite as it would defeat the purpose of using ClickOnce to distribute/update the product.
What is the correct method to incorporate all of our necessary files/projects into a single ClickOnce distribution?
The IDE won't detect native DLLs as dependencies when publishing, but you can run the SDK tools directly to include them manually in your ClickOnce distribution. You can either use mage.exe in your post-build script or run MageUI.exe to have a wizard to guide you through the package generation.
Suggested reading:
Walkthrough: Manually Deploying a ClickOnce Application
Understanding Dependencies of a Visual C++ Application
There is an alternative to Visual Studio for this kind of situation. You could try using Mage, but it can be a little tricky to use. My company wrote an alternative called ClickOnceMore.
ClickOnceMore is a ClickOnce build tool for when you don't want or can't use Visual Studio to do ClickOnce builds.
There is a specific page on the UI for including files (using rules to include anything from a single file to an entire directory trees) so you should be able to do exactly what you need with it.
This is what I have done in a similar situation. I use TFS at work, so convert the terms to whatever you may use (or not use) for source control.
I have a main workspace that I use for all development of my application, I keep this workspace pristine.
I then created another workspace with a proper name (ex: solution-deploy) and in this workspace I do the following:
Get latest and merge everything from source-control into the deployment workspace
I build a Release build of my application
I r-click on the root (I put them in the root, because I need to access them from there, put them in whatever folder you want) project folder for my deployment project and select "Add -> Existing Item"
I browse in the file selector to the Release directory of the assemblies I want to add to my deployment package, select them, then I use the arrow next to the Add button and drop down to "Add As Link", do this for all of the assemblies you want to add and place them wherever you want them to be organized in your deployment
In the Solution Explorer, select the added assemblies and in the Properties window set the Build Action to "Content", this should be all you have to do, but others have had to also set the "Copy to Output Directory" to "Copy Always", I don't do that
Run a Release Build
Go to the Properties view for your deployment Project
Go to the Publish Tab and Click on the Application Files button
Your files should all be available and added to the Deployment
Set up your ClickOnce settings however you need them to be
Publish your ClickOnce package
Your published package should contain all of the assemblies you need now.
Keep your separate Deployment workspace set up this way and never check it in. Do your work in your development workspace. Whenever a new deployment is needed, open your solution in your Deployment workspace and get the latest code, build, then publish.
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.
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.