We Keep Coding

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.

Where to put the DLL in C# source?

I just built https://snowballstem.org 's C# port.
It makes a dll I can reference in my project
<ItemGroup>
<Reference Include="Snowball">
<HintPath>..\..\..\snowballstemmer.dll</HintPath>
</Reference>
</ItemGroup>
What's the best place to put that (and other such) dll so that my codebase remains well-structured and portable and other developers can join in development very easily after cloning it?

As mentioned in the comment by mason, for .NET project it recommended to references to NuGet packages. However if you, for some reason, need / like to keep the libraries you use in a repository, you can use a file structure like this:
1 YourSolutionName
1.1 src // sources
1.1.1 project 1
etc.
1.2 libs // libraries / dlls you reference
1.2.1 library1
etc.
1.3 docs // documentation
etc.

It is true, we really don't want to have dll references in our code repo, if possible. However, if the target project does not have a NuGet package then it's not really possible.
Assuming you have a project folder and a solution file outside of it, I would create another folder, called something like ThirdPartyDlls and chuck in there. You can then add a reference to it in your project, making sure you use a relative path to it. This can be changed in the project file if necessary.
If you use Git for your source control, you can force push dlls.
Now, I am not a fan of this method, but sometimes you just don't have an option.

Can a COMReference be fully migrated to PackageReference?

I am trying to rid myself of a lib-Folder I have in my solution, migrating dlls to nuget and also switching from Packages.config to Packagereference.
That worked well for most dlls.
But now I have some COM-References I am unsure if what I am trying to do is correct.
It looks like this in .csproj:
<COMReference Include="MyLib">
<Guid>{ABCDEFA1-AD1F-AFBE-ACED-AFDF123AADEE}</Guid>
<VersionMajor>X</VersionMajor>
<VersionMinor>Y</VersionMinor>
<Lcid>0</Lcid>
<WrapperTool>tlbimp</WrapperTool>
<Isolated>False</Isolated>
<EmbedInteropTypes>True</EmbedInteropTypes>
</COMReference>
And as a prebuild-event I have
<PreBuildEvent>
regsvr32 /s $(SolutionDir)Lib\MyLib.dll
</PreBuildEvent>
Now I am irritated, because I read this article where it told me to add ReferencePath and EmbedInteropTypes via .targets from the nuget-package.
However I did not get this to work (or it seems it did not suffice in my case (looking at the GUID being referenced in the COMReference))
So this got me thinking, maybe I do not need to transform this into a Packagereference at all, but just add one (that includes "MyLib"), have the prebuild-event go against that dll from my packages-folder and leave the COMReference as is.
I now just added the libaries I needed to the nuget package I am pulling under content\x86 and modified the prebuild-event to point to $([MSBuild]::EnsureTrailingSlash('$(NugetPackageRoot)')) instead.
This seems to work, it builds, and I have no runtime errors (so far), but I am not sure if this is best practice or if I am missing something, any pointers are greatly appreciated.

Build project's components to own .dlls

I have project, which contains lot of classes. I use this project as plugin base for one of my application. This app can load all these plugins from one .dll builded from this project.
Problem is, I need to use these plugins in third-side app. This app can load only one plugin per .dll. I have very few options here. As far as I know, I could create new project for each file and build them. But it is sloppy way how to solve it.
So, is there any way, how to build one project for each of its classes or for groups of classes?
It sounds to me as task for some script. Is possible to achieve this for example with psake or powershell?
Thanks in regards

Well, I believe that they are already doing that in their own bin directories.
That`s if you mean assemblies as components. If you are talking about classes, then you should place them in separate assemblies and use the same approach.
You can right click on assembly and go to properties, build where you can see the 'output path' field as well as 'XML documentation' checkbox which is required for third-side apps to see your XML comments while using .dll-s.

One way I can think of is to create a 'template' project file based on the Plugin project you already have. You can make a copy of the plugin.csproj and then delete all included plugin classes. Using psake and Powershell you can dynamically add the plugin class you need an assembly for and then call MSBuild to build the csproj.
<ItemGroup>
<Compile Include="MyFirstPlugin.cs" />
</ItemGroup>
Adding xml-nodes like this to an csproj-file is easy to do in Powershell.
The pseudo code for the ps script could be something like this;
define list of plugin cs-files
for each plugin cs file
copy template.csproj to plugin.csproj
add xml node to include plugin.cs file
call msbuild on plugin.csproj
delete plugin.csproj file

MSBuild .NET project that will output existing assembly as it's result

I need to create csproj file that will be usable as project reference in VS2013 and will output prebuilt binary as it's "Build" result.
We use referenced projects for build, however company policy doesn't allow access to some of that projects for everyone. As a result projects need to be updated manually to make them build. This is really a major inconvenience when switching branches and when making edits to project files, so I want to create dummy project that will be bound to pre-built binaries as their "output" and will be placed instead of real projects.
EDIT: Moving that assembly to Nuget package is not an option for now since Nuget has some issues with dev flow (when you need to debug/test/develop package). I saw some VS extension that implements switching between Nuget package and local project which might solve this issue, but I'm not sure if it will be accepted and want to explore other options.
To be clear - the thing I want to avoid is editing project in any way, so that project can be built cleanly after pulling it from Git, and I don't have to clean it every time before commit.

I haven't properly tested it, but the solution seems really simple (if I understand the question properly).
Just add this to the existing .csproj, overriding the Build target to just give the path to the pre-built assembly.
<Target
Name="Build"
Returns="$(TargetPath)" />
This assumes the TargetPath property already defined, and it should automatically be if you're modifying the original .csproj. Otherwise just define it yourself in a <PropertyGroup> before the Build task.
Note that having TargetPath defined is important for the ProjectReferences in your own project to resolve.

How about having those restricted (binary only) projects reside in an internal Nuget package feed, so that Nuget can install the packages as needed, on build?