We Keep Coding

How to tell Visual Studio (MSBuild) to copy all files in the folder, including empty folders?

I have a Template folder in the project that should not be compiled or anything but should be included when built so my app can copy it later. The content may include C# files as well. I previously use this declaration to copy everything:
<ItemGroup>
<Compile Remove="Template\**\**" />
<Content Remove="Template\**\**" />
<Folder Remove="Template\**\**" />
<None Include="Template\**\**">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>
</ItemGroup>
However today I realize it doesn't include empty folders. I would like to use a wildcard declaration instead of separate <Folder Include="..." /> like other articles on SO as the content of Template may be changed later and I do not want me or my teammate forget to add it. Is there such declaration?

There isn't a flag or declaration or metadata for the CopyToOutputDirectory feature that will make it copy empty directories.
The CopyToOutputDirectory feature uses the Copy task and the Copy task doesn't copy empty directories.
There is discussion/feature requests about MSBuild copying empty directories so this may change in the future but it is not available today.
In the general case the question should be asked, does the copied directory structure really need to have empty directories? Can it be acceptable (or made to be acceptable) that an empty directory is not included in the output? For example if the directory structure is consumed by code, can the consuming code be updated to gracefully handle 'missing' directories?
For when empty directories are required, two approaches are:
Create a custom MSBuild target that statically builds the expected directory structure in the output directory. This target would be straight-forward to implement, it could be a single MakeDir task, but would require maintenance (i.e. changes) whenever the directory structure changes. If changes are infrequent, this may be fine.
Create a custom MSBuild target that dynamically walks the directory structure and creates matching directories in the output directory. This target would require more effort to implement but won't go 'out of date' when the directory structure is changed.
If these tasks are non-destructive and only add missing directories, they could be run either before or after the CopyToOutputDirectory step happens in the build.
If one of these targets is implemented, it would be a good idea to also implement a target that is invoked on a clean that removes the directory structure.

Copy a file to other project using Nuget package

I am trying to get my head around how Nuget works when creating packages and must admit that I cannot grasp it.
To generalize my task, it is to include a file in the Nuget package, create that Nuget package and when installed as a dependency in other project, the file is shown there in the project structure or somewhere to be manipulated with.
This file is a central .DotSettings file which would then propagate to all the C# repositories and solutions.
Where I am now
I have a .dll project, I have my content folder where the file is and I specify that within the .csproj file as such:
<ItemGroup>
<Content Pack="True"
PackagePath="\"
Include="content\test.DotSettings" />
However, when this is Nuget packed and this dependency is installed in another project, I cannot see this file in the project/dependencies/packages folder, where I would like it to be (and I suppose it should be there, right?)
The workaround I have now is that I reference this file from within the users/nuget/packages folder, however, I do not fancy this solution that much.
So, the main question:
Is there a way to copy the file so that when the dep is installed, the file is shown at the top level project folder structure? if so, what am I missing?
misc questions:
As I understood it, I can write my own .nuspec file and specify it there somehow, but when I did that, at build it always overrides it with its own autogenerated .nuspec file. Is this a wrong way to take at all and should I not create my own .nuspec?
What about the .target and .props file, what is that for and do I need to bother with those in my task or not at all? From what I understood, I should be good with my .csproj file and be able to define it all within it.
TIA!

Include NuGet Utility Package when building csproj

I need to use a NuGet package containing a utility for my project. It contains several binaries (EXEs and DLLs).
I've added it to my project successfully but I suspect the nupkg isn't formed correctly because I cannot use any of its DLLs or EXEs in my project without manually pointing to the package in my local NuGet cache. When compiling, none of its resources are added to the output (I assume this is because nothing is referenced in my code).
I'd like to create a wrapper project to call the binaries but I'd also like other project devs to be able to compile the solution without adjusting directory variables. Ideally, I could configure the csproj to pull in the bits directly from the local package cache. I think this would be possible by setting the Generate Path Property value to Yes in Visual Studio, but the variable cannot be found when I attempt to use an <Include/> statement in the csproj file.
Is what I'm asking possible? Namely, reference the NuGet package bits within my csproj to ensure the binaries are dropped in the compilation output? Can I do this with the Path Property, or is there something else I can do without directly committing the package's binaries into my project?
(I realize I need to work with the developer to fix whatever issue they have with their package, but I have no direct influence at the moment so this is the best I can do at the moment).

I figured this out, mostly due to misunderstanding how some of the different tags and attributes are meant to be used.
To achieve the desired effect, I did the following:
<ItemGroup>
<Content Include="$(Pkg{PackageId})\**">
<Link>{NameOfSolutionDirectory}\%(RecursiveDir)%(Filename)%(Extension)</Link>
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</Content>
</ItemGroup>
Where {PackageId} is the name of the NuGet package (this step requires setting 'Generate Path Property' to 'Yes' in the package properties via Solution Explorer), and {NameOfSolutionDirectory} is the name of a folder within the solution I'd like to use for containing those bits, if you're as concerned about keeping the project as organized as I am. The {} should be excluded when replacing these values.
If you want to scope to a specific directory within the package contents, do it within the Include attribute. The ** is necessary if you want to include all files within that directory, or else you can scope by extension or whatever additional pattern you'd like.

How to tell nuget to add package resource files as links, and not copy them into project directory

Intro (how to pack resources into a nuget package)
To pack some resource files into a nuget package, what one would normally do, is the following.
Put all the resource files into the content\ directory of a nuget package. This would be specified by the following line in a .nuspec file:
<files>
<file src="Project\bin\Release\script.js" target="content\js\script.js" />
<files>
Now, when this nuget package gets installed into AnotherProject, the following file structure emerges:
Solution.sln
packages\Project.1.0.0\content\js\script.js // the original resource file
AnotherProject\js\script.js // a physical copy
AnotherProject\AnotherProject.csproj // <Content /> tag (see below)
During package installation, AnotherProject.csproj was injected with tag:
<Content Include="js\script.js" />
and this is for the physical copy of the original resource (which is under packages\ directory).
The actual problem (how to pack resources into a nuget package as link)
My aim is not to have the physical copy of a resource file in the AnotherProject directory but rather a "link" to the original resource under packages\ directory. In the csproj, this should look like this:
<Content Include="packages\Project.1.0.0\content\js\script.js">
<Link>js\script.js</Link>
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</Content>
Brute force solution that I would rather avoid
Now, one "do it the hard way" workaround I can think of is:
not putting resource files under content\ so they do not get added automatically,
writing Install.ps1 script that would hack the csproj file structure and add the necessary XML piece manually,
This, however, has the following drawbacks:
all my nuget packages need the same script piece in their Install.ps1,
when installing my packages, there would be a nasty "project reload prompt" in Visual Studio.

Since NuGet currently does not support this out of the box your options are either to use PowerShell or to use a custom MSBuild target.
PowerShell
Leave your resources outside of the Content directory in your NuGet package (as you already suggested).
Add the file link using PowerShell in the install.ps1.
You should be able to avoid the project reload prompt if you use the Visual Studio object model (EnvDTE). I would take a look at Project.ProjectItems.AddFromFile(...) to see if that works for you.
MSBuild target
NuGet supports adding an import statement into a project that points to an MSBuild .props and/or .targets file. So you could put your resources into the tools directory of your NuGet package and reference them from a custom MSBuild .props/.targets file.
Typically the custom .props and .targets are used to customise the build process. However they are just MSBuild project files so you could add items for your resources into these project files.
Note that .props are imported at the start of the project file when a NuGet package is installed, whilst .targets are imported at the end of the project.
Customising NuGet
Another option, which would take more work, would be to modify NuGet to support what you want to do.

VS Solution with C# project dependant on C project, best pratice [duplicate]

How can I set up a project in Visual Studio to copy the third-party DLLs that one of the project's references depends on?
I have a main application project and a class library DLL. The main application references the class library DLL, and the DLL itself references some third-party DLLs. When I compile the main application, it automatically copies the class library DLL to its output directory, but it does not copy the third-party DLLs.
I do not want to add references to the third-party DLLs from the main application project because the main application does not use them, they're only used by the class library.

You can achieve this with the project properties window. Visual Studio allows you to define events to occur, before, or after building. To get to the project properties window simply right-click on your project in the solution explorer window and click on 'properties'. From the left hand side go to the 'build events' tab.
In the post-build box type in a few copy commands. For example:
copy "$(SolutionDir)mydll.dll" "$(TargetDir)"
Where $(SolutionDir) and $(TargetDir) are both predefined variables. The standard syntax is as follows:
copy "source directory and file name" "destination directory"
If you click on the 'edit post build...' button it will bring up a box which has a listing of these predefined variables that you can insert (like $(SolutionDir) and $(TargetDir))
As a side note, this is a useful process for copying other files, such as custom configuration files, images, or any other dependencies your project may have.

The following fragment works for me:
<Project>
...
<ItemGroup>
<Content Include="Path\to\dll\dllname.dll">
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</Content>
</ItemGroup>
...
</Project>
This works for C#.
For native C++ it still copy dll to output folder, but this dependency is not visible in Visual Studio, it should be edited in project file directly.
To test on non-trivial example
I tried to run C# project A which depends on native C++ project B. B projects depends on thirdparty native dll C - this dependency is implemented via fragment above in project file.
When I build A, C is copied to binary folder.
I tried it in Visual Studio 2010.

Take a look at this solution provided by Alex Yakunin
http://blog.alexyakunin.com/2009/09/making-msbuild-visual-studio-to.html
It worked for me really nicely - the scenario being DevExpress libraries expressly used had other dependencies which caused problems when deployed)
Note 1: Visual studio 2010 seems add referenced dlls automatically, however msbuild didn't. So Alex's solution worked since the release scripts used msbuild.
Note 2: Also had to make sure that for the referenced libraries (those which were referenced in code) copy-local was actually set to True in the csproj, even though the Solution Explorer said it was. The best way is to set copy-local = False, Save, set copy-local = True, Save.
These two steps - copy-local=true for referenced libraries and adding msbuild targets for the indirect references automated the build setup for me.

I would not recommend doing this. You end up with an N^2 explosion in the number of assemblies being copied around (and potentially, being rebuilt). If possible, you should have all of your projects place their assemblies in the same $(OutDir). If you're using TFS, Team Build does this for you.

I don't like to have my dependency files located in the project root folder but in a subfolder. But the files has to be placed in the root folder in the build folder.
My build events look like this:
Command: call xcopy /S /Y "$(SolutionDir)Dependencies\*.*" "$(TargetDir)"
In case "Dependencies" also contains subfolders, as mine does.
/S means to copy subfolder also
/Y means to not prompt for overwrite confirmation
Other xcopy parameters can be found at: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/xcopy

Go to the main application, references, to your class-library reference.
Set "Copy Local" to True.
It will now copy the bin directory of your class-library into the main application bin directory. Including any sub-dependency third-party dlls.

If you want to copy new file only in post-build, you can also use xcopy with flags /i /d /y
xcopy "$(ProjectDir)SubDir\*.dll" "$(TargetDir)" /i /d /y

100% sure this will work.
Just replace dll with your personal ref. file
<Reference Include="Xceed.Wpf.Toolkit">
<HintPath>..\..\..\3rdParty\Extended WPF Toolkit-2.2.1\Xceed.Wpf.Toolkit.dll</HintPath>
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
<SpecificVersion>False</SpecificVersion>
</Reference>
<Content Include="..\..\..\3rdParty\Extended WPF Toolkit-2.2.1\Xceed.Wpf.Toolkit.dll">
<Link>Xceed.Wpf.Toolkit.dll</Link>
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
<SpecificVersion>False</SpecificVersion>
</Content>

I'm not really aware of any way to do this other than adding a reference to said .dll in the project itself. We've run across this in some of our own projects here, and the only solution we've found is to add the reference. I want to say that one of our developers did some research and found this to be the only solution, but don't quote me on that.