Develop Reference

What files are mandatory in release windows form?

I have files in ...bin/release where is my windows form application, I have used EEPlus library as well. What the files do I need to send to client to have application work correctly?
My files:
name.exe
name.exe.config
name.pdb
name.vshost.exe
name.vshost.exe.config
name.vshost.exe.manifest
EEPlus.dll
EEPlus.xml
I know that first two are mandatory, but what about all rest?
thanks in advance

name.exe //necessary, it is your main executable
name.exe.config //necessary, it is your application config file
name.pdb //not necessary, it contains code and debug symbols configuration of your assembly, but let it be there, it is useful when users encounter a bug or crash
name.vshost.exe //not necessary, it is the hosting process of visual studio for debugging purposes
name.vshost.exe.config //not necessary, config file of name.vshost.exe
name.vshost.exe.manifest //not necessary, manifest of name.vshost.exe
EEPlus.dll //necessary, it is one of your application dependencies
EEPlus.xml //not necessary, contains some information for EEPlus.dll
reference for xml, reference for vshost, reference for pdb

All except *.pdb and *vshost*.

Really you should look at the REFERENCES of your project.
Generically all the assemblies that don't make part of the NET Framework need to be redistributed.
In this case, it seems that you need to distribute EEPlus.dll only.
The other files are there just as a byproduct of the compilation.
Of course, you should also consider that a thirdy party library could need other files, but this should be explained in their documentation under the redistrubute page.
You could try this:
Delete all files except the name.exe, name.exe.config and EEPlus.DLL, then run your app outside VS directly in the BIN\RELEASE folder. However I recommend to have a clean virtual machine where you could test your app and be sure to not forget anything.

Always
name.exe
name.exe.config
Dependency dlls
Interop dlls
First we check this mandatory files before giving to client, because at client, when running application that will be crashed without displaying any errors...

referencing and importing third party python libraries

I am fairly new to python, and come from a C# background. In C# l, third party libraries are commonly stored inside the project folder.
This means that libraries are totally internal to the project. The project then is not dependent on anything outside of the project folder (other than .net framework of course).
I really like this structure and have tried successfully to mirror this in python by copying the libraries into a lib directory, in the project root, and adding the lib folder to the python path on startup of the application.
I am worried that there may be something I am overlooking by doing this as I have looked around a bit amd have not really seen anyone else in thw python community doing this.
My question is simply - is this ok? Is there something that I may miss by simply dumping the necessary .py libraries in, rather than using easy install, and thus storing the libraries in site packages, at a system level?
Please feel free to let me know of any drawbacks you can see, no matter how simple.
Thanks!

I'll espouse the usage of virtualenv and pip for development purposes. This will give you exactly the sandbox that you are used to. As for distribution, use setup.py and reuse the requirements.txt file that you would use with pip install -r to install dependencies to generate the install_requires argument to setuptools.setup. I've been meaning to set up an example that shows this off a little - check out https://github.com/dave-shawley/setup-example for a nice example with some description too. I plan on adding a little more to this as time allows.

If you want to closely manage the dependencies of your code on the per project basis you might want to take a look at virtualenv.
Virtualenv will allow you to keep your dependencies close to your source but will remove the error prone manual copying of the .py files.
On top of that remamber that some packages are not pure python and they sometimes contain compiled C code - if you use virtualenv you do not have to worry about it.

Couldn't find the final merged executable file location for ILMerge

For past few days, I had been struggling with Merging assemblies inside a single executable file. So that I can distribute the single executable file to my users. I found out ILMerge to do this apart from ILMerge, there are few more tools that seem to do it. I tried BoxedAPP Packer and SmartAssembly also .NetShrink seems to work good but all are paid tools. So, I wanted to complete the task with ILMerge and after much of browsing and searching Google and from StackOverflow, I found out the solution.
I tried the below set of lines for merging the assembly
c:\"Program Files"\Microsoft\ILMerge\ILMerge.exe"
/lib:"C:\Windows\Microsoft.NET\Framework\v3.5"
/lib:"C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PublicAssemblies"
/t: winexe
/target:exe
/targetplatform:v3.5,C:\Windows\Microsoft.NET\Framework\v3.5
/out:”MergedProduct.exe”
"$(TargetDir)Product.exe"
"$(TargetDir)CButtonLib.dll"
"$(TargetDir)Common Tools.dll'
"$(TargetDir)Core.dll"
"$(TargetDir)ProgressIndicator.dll"
"$(TargetDir)TaskScheduler.dll"
I used this above set of lines inside
Build-Events > Post-Build event command line
and after building the project I got as build succeeded. Also while building the application runs as if i have pressed F5 to start debugging. So, to summarize up, I'm sure the above set of lines are correct but i couldn't find the output executable file (i.e MergedProduct.exe) anywhere. I also tried using the Release mode of the Visual Studio 9.0 but still i couldn't find the Output merged executable.
Is there something really obvious that i'm missing?
Also, can I merge Product.exe.config file using ILMerge?
Any help or suggestions would be really appreciated.

Is that codeblock a cut and past of the command line? I notice you have fancy quotes around the /out filename. Also, have you tried adding a folder to the /out filename (eg, $(TargetDir))? We do that in our build process to save it in a particular publish folder.
ILMerge will allow you to merge the xml documentation, but not the configuration files (as far as I'm aware).

Whats a good approach for white labeling dll

Whats a good approach for white labeling dll and exe with visual studio?
In essence we want to be able to have the name of the dll and exe change based on the client that we are packaging the solution for, e.g.:
Instead of myCompany.exe and myCompany.db.dll, I would like yourComany.exe and yourComany.db.dll or acme.exe and acme.db.dll, etc
Edit:
Currently we are using a straight visual studio build process with a wix project to create an msi.

If the only justification for rebuilding it is to change the name, can you just use something generic in the first place? Imagine having to patch 50 identical DLLs, and build/deploying each one separately because they all must be named different things. Even if it's only for a few clients, I would hate to have to maintain that. Versioning could be a hassle too.
If you must do it, I would probably go with a build task (which can perform fairly advanced operations). You mention that you are "packaged the solution"; the viability of a build task would depend on how it is being packaged.
In response to your comment about naming the EXEs with client-specific names... My obvious suggestion there would be to have those applications contain as little code as possible.
The simplest build integration I can think of would be to create a post-build task which ran upon successful compilation in release mode. The task could then read a config file which defined the unique names, and copy the successfully built EXEs to an output directory.
Some of the operations can be accomplished just from the task config file: http://msdn.microsoft.com/en-us/library/ms171466.
Alternatively, you might want to create a little application to do all the work for you, and just pass config switches to it.
For example, here is a little post-build command that I execute to minify my JavaScript/CSS upon successful build of a web application. The concept is similar:
build
execute an app (like msbuild.exe, or your custom build app)
pass data to the executable (like paths, switches, etc.)
executable writes the files out
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe
"$(ProjectDir)Properties\build\minify.xml"
/p:SourceLocation="$(ProjectDir)client"
/p:CssOutputFile="$(ProjectDir)client\final\final-full.css"
/p:JavaScriptOutputDirectory="$(ProjectDir)client\final"

You could use ILMerge in whatever post-build process you want on all your outputted assemblies (dll and exe), to create one-off customer-branded builds.
ilmerge /out:CustomerName.exe internalName.dll internalName.exe

I don't know that there is a good way to do this without actually building the project as XYZ company. You could try something like this which will give you the desired result BUT it will change the physical name of the assembly as well which may cause dependency problems.

Custom build step for C# project

In C++ projects there is the possibility to set a custom build step for files. Is there a similar functionality in C# projects? I couldn't really find anything.
One idea would be to create a second project (makefile or c++) and move the files there.

MsBuild should work for you although it might take some time to figure out how it works. It appears that you can setup a step that runs prior to building each .cs file by separating each .cs file into its own build group.
In MSBuild script for compiling each .cs file into an EXE, Dino Chiesa comments:
By using the %(CSFile.identity)
scalar, we run this task once for each
file. The converse would be
#(CSFile.identity). That would run
the compile once, for all files,
compiling them all together into a
single assembly.
Also, these links might help:
Custom build step for C# files
Master Complex Builds with MSBuild

No custom build step for individual files with C# projects. You could probably hack something together with MSBuild...

Look at the BeforeBuild and AfterBuild targets in your csproj file.

I think you are on the right track with your comment about multiple projects. Combine this with the fact that you can include multiple projects within a single Solution and you may have your answer. I use this functionality to build several components at a time and it works quite well.