i am struggeling for a while now with removing unused dependencies from bin output folders.
I am for example writing a small .NET Wpf program which gets its data from a Web server. Therefore i installed the System.Net.Http NugetPackage to make my Get / Post requests. The Package Information is stored in the .csproj file.
When i compile the project a lot of Dependencies are added to the output folder
Sytem.Security.Cryptography.Algorithms.dll
Sytem.Security.Cryptography.Encoding.dll
Sytem.Security.Cryptography.Primitives.dll
Sytem.Security.Cryptography.X509Certificates.dll
...
None of these dependencies are explicitly used in my program, means when i delete them from the output folder and start the application everything works as expected.
I do understand that this Dlls has to be in the package, but how can i ignore them. Is there a way to ignore dependencies within a nuget package?
One way to accomplish this is to set copy local to false on the Dll reference.
I haven't worked on WPF projects but I believe this would still apply.
To do this expand the References node in the project, select the Dll and then in the Properties window set the "Copy Local" property to False.
This should prevent the Dll from going into the bin and also from being included when published.
One word of warning though, the application may work now but doing this creates a potential trap for future you or other developers. If code changes down the road require one of these Dlls your application won't be so happy and then you'd have to remember to put the Copy Local back to True.
Related
I have used Specflow/MSTest to create a test suite. I need to be able to package this so that a third party can run the tests etc.
I can use vstest.console.exe to execute the features/scenarios using a number of .runsettings I have.
Problem I have is how to copy the files from the Microsoft.TestPlatform nuget package to my project output folder (whether same folder, sibling folder whatever; that is not an issue, I can work that out no worries). I just can seem to work that out.
I have read a number of posts, on SO and elsewhere, with folk asking same/similar questions but I just cant repro how to do it.
Have tried editing the project file to copy PackageReference 'always', using the 'None' element etc but just can't seem to get it. Microsoft.TestPlatform is used extensively so I'm guessing that i'm missing something simple here; I just cant get Google to be my friend in this instance.
So, if my .NET5.0 (framework may be irrelevant) project has a Nuget Package referenced but is not referencing it in code anywhere how do I instruct Visual Studio to copy the files from that package to whatever folder I need them to go when I do a build?
Try to modify the package management to "Packages.config", it will auto copy the dlls to output folder.
If you want to copy dlls to other folder, you can use xcopy command in post-build event.
dotnet publish is the command you're looking for
dotnet publish compiles the application, reads through its dependencies specified in the project file, and publishes the resulting set of files to a directory. The output includes the following assets:
Intermediate Language (IL) code in an assembly with a dll extension.
A .deps.json file that includes all of the dependencies of the project.
A .runtimeconfig.json file that specifies the shared runtime that the application expects, as well as other configuration options for the runtime (for example, garbage collection type).
The application's dependencies, which are copied from the NuGet cache into the output folder.
https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-publish
I'm evaluating TFS Build 2013 for use in a corporate environment.
TFs itself has been running fine for ages, and today I setup the Build components. No problem so far.
I grabbed a fairly simple project from source and created a manually triggered build definition, using the standard defaults.
I ran a test build and hit an issue straight away with a primary reference. The error in the logs is:
C:\Program Files (x86)\MSBuild\12.0\bin\amd64\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "XYZ.dll".
So a bit of back of background on how we store and use references:
We create a root folder for the solution, inside this goes the .sln file and sub directories for the projects as normal. We then add a "References" folder at this level, which holds all of the DLLs required for the project. These are generally DLLs from other in house code libraries, but also certain 3rd party ones (such as the old Enterprise Library DLLs, and anything else we don't get from NuGet).
Each of the projects that require these DLLs reference this folder (and from inspecting the .proj files I can see the link is stored as "..\References\XYZ.dll" etc. This works fine for local builds and nobody has ever had an issue. The reference folder gets checked into TFS and everybody gets a copy. From what I've read through trying to diagnose our issue, this is a fairly common and accepted way to manage references.
So, the build error that I receive is as above. Basically saying the build target can't find the DLL from the References folder. The log goes on to list all of the places it's tried to find it.
Crucially (it would seem) the first line reads:
For SearchPath "{HintPathFromItem}".
Considered "..\References\XYZ.dll", but it didn't exist.
Furthermore it looks in the Framework folder, various default assembly folders, the GAC and so on, none of which (of course) contains it.
So I'm wondering where I've gone wrong. Have I misconfigured one of the build/drop locations? Is there some other convention for referencing required DLLs (bearing in mind our entire company uses the "..\References" folder setup, or is there something else?
I'm fairly new to TFS Build, but I'm by no means new to TFS or Visual Studio
itself. I've spent about an hour or so Googling without finding anyone experiencing the same issue as me, so any help would be greatly appreciated.
Thanks
UPDATE:
The build agent is configured as follows:
Build Agent- working directory:
D:\BuildAgent\$(BuildAgentId)\$(BuildDefinitionPath)
The build definition "Source Settings" have the (I assume) default values of:
Status: Active | Source Control Folder: $/ProjectRoot | Build Agent Folder: $(SourceDir)
Status: Cloaked | Source Control Folder: $/ProjectRoot/Drops | Build Agent Folder:
The references folder is not explicitly configured here, but when I look in the Build Agent's working directory I can see it:
D:\BuildAgent\1\ClientName\SolutionName\src\Dev\Evolution\Source\SolutionName.Solution\References
If I open VS2013 Command Prompt, navigate to the folder that contains the .sln file (and also the References folder) and run "msbuild d:\path\to\Solution.sln" then it builds successfully with no warnings or errors.
Well it turns out this wasn't a fault with TFS at all...
The problematic DLL, although present in the References folder, was not actually checked into TFS.
Right clicking the References folder in VS (added as a "Solution Folder") and selecting to Add Existing Item, then a check in fixed the issue.
So the References folder was being used as you would expect, in the same way that VS uses it. MSBuild worked locally because I had the file in my local folder, but because it wasn't part of the solution it wasn't with the rest of the source.
I've got a TFS project with a NuGet package installed, and it references an assembly from that package. However, another copy of the same file is in a folder in the tree, and it is somehow overriding the reference and being used instead.
Even if I remove the reference entirely and manually point it to the correct path, the other file still is recognized and overrides the path.
Actual Case:
Correct Reference Path:
c:\Stratigen\Stratigen\packages\MonoGame.Binaries.3.2.0\build\net40\MonoGame.Framework.dll
Overriding Reference Path:
c:\Stratigen\Stratigen\Stratigen\Tools\MonoGame.Framework.dll
The file in "Tools" needs to be there because it is a build against SharpDX (API wrapper for DirectX) and is used to compile shaders for multiple versions of MonoGame, while the game should be running against the OpenGL version (unless I were to purposefully change something).
The especially odd thing about this is that I've had this file in the "Tools" folder this entire time, and for weeks never encountered this issue, yet now it's got this odd behavior.
It seems that having included the "Tools" directory in the project was to blame. This folder is already handled by TFS but since there are a few source files in there (for the shaders) I'd included the folder. However, this for some reason gave priority to the DLLs there over those from the packages. I'm going to re-add the source files but not the DLLs/EXEs from that folder and it should work fine then.
I have a couple of different solutions, in which some projects may depend on output from projects in other solutions. To manage this, I've been copying dll files from the /bin/ folder in each project to a shared library location after build, and then copy/reference them from there to the dependent project.
However, as the library solution gets larger, this tends to become unmaintainable. Too much of my time is being spent traversing solution directories in Windows Explorer looking for /bin/ folders, and trying to figure out which one, or which ones, of the dll files from each one I need.
Is there any way to give Visual Studio a hint that I want all projects in a solution to have the same output directory? For example, a /bin/ folder directly under the solution folder, where all projects put their output.
If possible, I'd like to achieve this without hard-coded post-build events that copy the files, since that will fail if a project output changes file name, or adds another file. I'd rather like to change the location of the actual output directory - the location of $(OutDir), if you will.
I know you said you don't want to use post build events, but your reason as to why not intrigued me. It sounds like you might be hard coding the name of the .dll in your post build event. That can easily be avoided.
xcopy "$(TargetDir)*" "c:\common\" /Y
The * would just cause everything in your bin/Debug/ folder to get copied to your common folder. You could also just copy dlls if you want. Or, if you use $(TargetPath), you'll copy just the 1 dll that is the result of the project, and not any other related dependencies.
UPDATE
The way we do it is each projects entire bin folder is copied to a subfolder. Suppose you have 2 projects, WebUtil and HtmlParser, where WebUtil depends on HtmlParser. For both projects, use xcopy "$(TargetDir)*" "c:\common\$(ProjectName)" /Y. This will create c:\common\WebUtil\ and c:\common\HtmlParser. In WebUtil, add a reference to c:\common\HtmlParser\HtmlParser.dll. There will now be 2 copies of HtmlParser.dll in c:\common.
c:\common\HtmlParser\HtmlParser.dll // the most recent build.
c:\common\WebUtil\HtmlParser // what was the most recent build when WebUtil was built
This has all kinds of advantages. If you change the API of HtmlParser, WebUtil will continue to work, since it will have the older HtmlParser.dll until you try to rebuild WebUtil (at which point you'll get build errors because of the changed API).
Now, if a 3rd project got in the mix that depended on WebUtil, and you're using some part of WebUtil that exposes classes in HtmlParser, then you'll need to add a reference to both projects from your new project. When you add a reference to HtmlParser.dll, use the one in c:\common\WebUtil. You do this because you're only including it as a necessary requirement of WebUtil. Now you'll always have the version of HtmlParser.dll that matches your current version of WebUtil.dll.
I hope that makes sense. It can definitely be a tricky thing to manage. Just wait till you have to start pulling down all your dependencies using svn:externals =P
You can set the output directory in each project properties.
Right click on the project, select Properties
For C#, it is one of the Build property page, under Output, Output directory.
In VB.Net projects, it is on the Compile tab, in the textbox at the top.
I have a Web Setup project in VS. I'll be switching to WiX, but that's in the future and currently I need to solve the following issue.
I need to exclude some common dlls from the project. So I build the project, VS updates the list of Detected Dependencies. I exclude them and the setup builds. I check the file list with Orca and the files are not included in the installer.
But when I clean my output directory, reload the solution and do the build, some of the dependencies do not show as excluded! And so they end up in the MSI. (This is what is happening on the build machine).
I think that the problem might be with the fact that these are second-level dependencies:
my app -> NHibernate.dll -> Antlr3.Runtime.dll
(Antlr dll ends up in the MSI).
Is this a bug or am I missing something?
I found this page on msdn that has a work-around for the Exclude flag being reset to False:
Previously excluded files are included again when the solution is re-opened
When you exclude a file from a Setup project, you may see that the file is included again after you close and re-open the solution. This may occur if there are two copies of the same DLL file from two different source locations.
To work around this error, change the Copy Local property on one of the files:
In Solution Explorer, click on the DLL reference that you want to remove.
On the View menu, click Properties Window.
Change the Copy Local property to False.