Develop Reference

Can you modify a csproj to be an empty utility project?

I would like to create a .csproj for a utility project. This project has no binary output, and is just used to group a bunch of other projects into a common dependency.
I am already using .csproj inheritance and custom targets so I am very comfortable with hacking the files and having no GUI support. Does anyone have a working "empty .csproj that can be used to build only its dependencies?
I don't want people to have to install any workload other than C# Desktop. That's why I am not using a normal C++ utility project, for example. I could obviously just build something that I don't actually distribute, but it seemed like there should be a cleaner solution.
Concretely, to address all the people asking me why:
I have one DLL that's basically a core SDK
I have a bunch of DLLs that are plugins or modules on that SDK
I have a few executables, each of which doesn't know the plugins exist but of course I want them all built first when I do a "Run" on the executable
So I group all the plugins under "All plugins", plugins each require and link the SDK, and each executable just depends on "All plugins" without linking. Obviously it links the SDK. Works great. Just that the "All plugins" project is a DLL I throw away :) and that seems ugly.

Understanding IlMerge - how to pack an executable with all it's associated dll's

I know I'm not the first person to ask this question on Stack Overflow and I'm sure I won't be the last. But, after spending hours researching how to do this and then physically trying to do it, I'm near ready to give up.
I have a .NET Framework 4, C#, WinForms application that builds to an executable. I rely on many many many dlls. The dlls fall into multiple categories.
Libraries I have written with no dependencies of their own
Libraries I have written with dependencies on other libraries I've written
Libraries I have written with dependencies on third party dlls
Third party stand alone dlls
Third party dlls with their own dependencies on other dlls
So after I compile my application I have a directory with an executable and approximately 15 dlls.
I want to pack all the dlls into a single executable so that I can simply distribute a single executable.
I know that IlMerge is the typically suggested application to use for this, but I'm curious if there is something easier to use that is more intuitive and works accross both WinForms and WPF.

The problem here is that ILMerge only can merge .Net assemblies. Your file lame_enc.dll isn't a .Net assembly but a standard Windows dll and therefore can't be loaded by ILMerge.
To get around this you could embed lame_enc.dll in your assembly and then extract it when needed in your application. Check out this article for more info on that.
http://weblogs.asp.net/ralfw/archive/2007/02/04/single-assembly-deployment-of-managed-and-unmanaged-code.aspx

In the end, I went an entirely different direction.
I decided to use the Costura Visual Studio Extensions located here.
These extensions use a combination of two methods
Jeffrey Richter's suggestion of using embedded resources as a method of merging assemblies
Einar Egilsson's suggestion using cecil to create module initializers
What's nice here is that you simply install the extensions into Visual Studio. After doing that, for any project where you want to pack your DLLs into a single executable, simply select the project, click Project on the menu bar, Costura, Configure, and then OK. It will ask you to reload the project - click yes. Now whenever you build the project it will create just a single executable (or DLL if you are doing it on a library). Couldn't be more easy.

ILMerge only combines pure (not mixed-mode) CLR assemblies. It works by extracting all of the CIL modules and then relinking them into a single new assembly. Assembly resources are also recombined.
ILMerge cannot merge native executable code. lame_enc.dll is a native DLL file and does not contain any CIL modules, that's why you can't combine it.
If you want to pack your application into a single executable a workaround is to include lame_enc.dll as an assembly resource, then save lame_enc.dll to disk in a temp folder perhaps, and add the folder it was saved in to your application's PATH, so your [DllImport] runtime linker will be able to access it.

To address your exact issue, verify that the file C:\Release\lame_enc.dll exists and that it is in fact a .NET file. ILMerge can only merge .NET assemblies.
Now if you are only worried about distribution of your application, you may consider creating an installer to install all of the binaries, and not worry about merging them using ILMerge.
Another alternative to using ILMerge is to embed the binaries in an assembly as desribed here.

Microsoft add-In with .net framework

I am extending an application using MAF in .net framework. I have implemented a pipeline and the required folder structure and it is working fine when I have the add-in implemented in one dll.
If I have a complex add-in where one dll implements the contract and a supporting dll performs the internal logic.
When I build this add-in project then the main dll and the supporting dlls are copied to the add-in folder and at that time the framework is not able to find the token from that folder.

You need to put the supporting assemblies into the GAC because the pipeline domains aren't able to resolve external dependencies from within the pipeline folders. Some of the interfaces in System.AddIn.Contract seem like they might be targeted for a scenario like you describe (IServiceProvider and IProfferServiceContract), but there are zero examples from Microsoft on how to use them.
It's a real shame that Microsoft has been so completely silent on MAF for the last two years. The lack of complex real-world examples is a big hindrance given the complexity of using it. The silence is deafening...

Add DLL in other Class Library to be used by actual project C#

I am wokring on a C# Win-Forms application. I have my own ClassLibrary (dll) file. I use another Third party dll for components. I use both of the above dll's in my C# application. When I provide the files I got to provide both the dll's seperately. Is it possible to add third party dll in my class library OR add both in a third dll and add only 1 dll in the project.
Also let me know how it is possible, as I am unaware with it. I use Visual Studio C#. Any help is highly appreciated.
Thanks

Try looking up ILMerge; it's intended to build composite libraries.

See Merging .NET assemblies using ILMerge for how to merge two assemblies
You can download ILMerge utility provided by Microsoft from here

you can merge the two libraries only if you have the source codes, then you can compile the two in one single assembly. other than that it might be well possible to merge the two assemblies but its gonna be a pain in the butt depending on each library. why bother? deploy both of 'em [:

Creating a Single DLL for Silverlight and Non-Silverlight

All of my cross-platform libraries are created with solutions that have two projects: one that builds on the Silverlight CLR and one on the regular CLR. Hence, every library I make has two DLLs: name.dll and nameSilverlight.dll.
This is, as far as I know today, the only way to do it.
However, I recently tried Mike Talbot's "Silverlight Serializer" DLL, and I could include the same DLL in a C# desktop and in a Silverlight application. It's the exact same file.
How did he do that? And how can I do that?
(I really need to do it, because I'm trying to serialize in a desktop app and deserialize in a Silverlight app, and the assemblies are not matching up because they're different.)

It may be that they are using the Portable Library CTP.

Silverlight 3 is a "lowest common denominator" and if you just use base/core classes, you can compile a DLL there and reference it directly from .NET. You cannot, without the portable library, do the converse however.