Develop Reference

How do I change the extension of a C# DLL when compiling with Visual Studio?

I am working with a C# based "Scripting" API. To have the application recognize my script i need to have the extension of the DLL be (libname.esapi.dll). I could accomplish this by changing the AssemblyName Property of the project, but I was hoping for a more elegant solution that would keep my fully specified names a little shorter for reflection operations in the future.
Is there a proper post build commandline to do this?

libname.esapi.dll
That is not a extension change. That is a file named libname.esapi with the extension .dll. Windows/the file System was given the abiltiy to support multiple points per filename in the last Milennium. Only the stuff after the last dot is the extension.
Added to the "feature" that it will hide extensions of some file types (like .exe), this has caused no end of accidental virus installations.

Can I use Orca to add a Custom Action to an MSI file, where the action is a C# method?

I have created an MSI file, but I want a specific C# method in the file to be used in a Custom Action that takes place prior to the ExecuteAction action in the InstallExecuteSequence table. Is there any way for me to update the Binary table in Orca so that it references a particular method in the MSI file?
For more information, my MSI file uses three separate C# class library projects. The method I want to use in the Custom Action is called InitialAction and is in a CS file called Initialise.cs in the Initialise project.

No you can't. Windows Installer doesn't natively support managed code custom actions. The Dll type referred to here:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa372048(v=vs.85).aspx
in a Win32 Dll with a standard required entrypoint signature. Managed code custom actions are typically implemented using a shim C++ Dll (Visual Studio) that calls into managed code, or C++ that calls out to an external process (WiX DTF). If you are using Visual Studio or WiX both offer support for managed code custom actions.
Having said that, what does your code do that it is required to be a direct call? Running an external executable is supported, whether managed code or not. The executable can call into the class libraries.
It's often useful to describe your ultimate goal. In effect you have decided that the solution to a problem is to edit the MSI, but there's no description of that actual problem. It appears that you want to modify an existing MSI to call code, but you don't want to rebuild it with the available tools.

stamping the username on c# assembly - who build this dll

So, here is what I am trying to do.
I am trying to stamp name of the user who compiled the particular project. As link assembly version is there any way by using that I can store the original user name on dll.
I tried creating custom attribute and using it in AssemblyInfo.cs, but it gives me the username of person who is running the dll and not who build it.
Any help will be appreciated.

For modifying the Assembly info I use a pre-build event that executes a batch file for the modification.

You could write a custom MSBuild action that updates an assembly attribute in a known file prior to compilation. This has the downside of having to install the custom build step on all dev machines and any build machines.

So here is I found I am trying trick.
I have created new custom attribute AssemblyCompiler. And by changing and using powershell script shown here . Seems it works.
Another C# solution
Create new custom attribute
write c# program to update/add username
call that c# code on prebuild event as follows
call ....\Resources\OverwriteAssemblyInfo.exe [ I placed my the executable file in resources]

A way to modify class (and general assembly) data at build time

This thing I want to do might not even be worth doing but I thought it would be cool.
So what I want to do is to have some code that runs when my project is building (not only when compiling), and adds stuff to my classes based on things like attributes and general code analysis. What I want to do is have dynamically generated fields/properties that are usable through intellisense, but not visible in the actual source.
The reason for that being that I might potentially want to generate a lot of them, and outputting them to source would turn into a mess very quickly.
The potential possibilities of a system like that would be stuff like vector swizzling.
Is there maybe a library of some sort for that that I could just plug my generation code in? If not, what would be the best way to approach this, if there is any?

The most visible example of this is done by Microsoft for XAML files. During the build, a C# source file is created for each XAML file and placed in the obj/Debug or obj/Release folder. In addition to that, the MSBuild .targets file where the relevant tasks are defined is specially configured to tell Visual Studio that the generated files are required for proper IntelliSense support, which means you don't actually have to explicitly build the project in order for IntelliSense to allow items declared in XAML to be used in C# code elsewhere in the project.
This is exactly the method I use for generating code for ANTLR grammar files during a build. You can see a complete example with a build task assembly and custom .targets file here:
https://github.com/antlr/antlrcs/tree/master/AntlrBuildTask
You should be aware that some 3rd party extensions for Visual Studio completely replace the IntelliSense support with their own implementation of code completion. Some of these extensions are known to not support the MSBuild IntelliSense extensibility features required for this to work with custom code generators. If you run into problems with IntelliSense and have any extensions installed, you may find that removing the extensions completely resolves the problems.

You should compile code by the class CSharpCodeProvider/ICodeCompiler/CompilerParameters when application run.

Is there a way to make user specific pre/post build events in Visual Studio projects?

I'm currently using a post build event in my project to copy my assemblies to another directory for debugging purposes. This is local to my machine, and is for debugging purposes only, so I would prefer to have it in a *.csproj.user file instead of a *.csproj file. I tried copying the responsible elements from the *.csproj to the *.csproj.user, but that didn't work.
Edit
To clarify, I do not want to put user specific commands in the post-build event in the *.csproj file. Instead, I want to put the post-build event commands in the *.csproj.user file. (From the answers so far, this is looking impossible)
To give more context, it is not a project reference. I am copying my assembly to the directory of the application that loads the assemblies at runtime. (Think plugins)

The short answer is no, not the way you want to do it :|
The slightly longer answer is sorta. You can in theory have specific build events triggered for individual users, but these would still be in the csproj file. You can run external events on builds and then allow these external events to run depending on what user is running them (as a script).
If this is for debug only I'd just insert them, do your build stuff and pull them out before uploading it to your version control system.

Use an if statement and an enviroment variable (in double quotes if required)
if "$(Username)" == "MyUser"
copy /y $(ProjectDir)memcached.$(ConfigurationName).config $(ProjectDir)memcached.config

You can utilize a custom build target that has a condition triggered by an environment variable. Then only set that variable on your machine.

Pre-/Post-build events are kept in the project file. VS provides no options.
You can introduce a custom (external) tool to perform such copying though and call it from menu, or macros and call it too.