Develop Reference

How to merge multiple .cs files into single .dll?

I am converting multiple .IL files into .cs, Now I want to create a single c# project with these .cs files. And then i want a .dll file for this project.
I have already created a c# project. I created a folder "Application" into this project. Now I am moving all the .cs files into this folder. After compiling this c# project i am getting its .dll file into bin folder.
Is this steps correct?

I use the Nuget Package Costura.Fody for it.
It merges everything into the target .exe, but maybe as Class Project it merges everything into one DLL?
You should give it a try:
https://www.nuget.org/packages/Costura.Fody/

The steps are correct as long as the result satisfies the initial task.
What you described sounds legitimate. Now it's your turn to check if the dll works as intended.

Renaming C# project to map to correct configuration

I have a created a C# console application that does something. Lets say its name is SampleTest. I use a config file named App.config in it. When I build this project, it creates files like SampleTest.exe, SampleTest.exe.config, etc. This is all fine.
My friend wants to execute this executable. So rather than sending SampleTest.exe and SampleTest.exe.config, I renamed the two files to DocumentManager.exe and DocumentManager.exe.config and gave it to him.
We noticed that this way, the DocumentManager.exe is not able to use the DocumentManager.exe.config file.
Please let us know what do I need to do in Visual Studio to this SampleTest project for it to generate DocumentManager.exe and DocumentManager.exe.config?
I tried renaming the SampleTest project to DocumentManager and building it but it still generates SampleTest.exe

Renaming the Assembly
Renaming the project on it's own is likely not going to be enough for what you are trying to accomplish. You'll need to ensure that you update the name of your assembly and namespace as well, which can be done through Properties > Application > Assembly name :
Changing the assembly name will change the names of your executable and .config files generated when building the project. It's probably worth changing your default namespace as well, just to keep things consistent.

You have to rename assembly. To fix this please do the following:
Navigate to project folder and find SampleTest.csproj file.
Open that file in some text editor like Notepad++. Find elements:
<RootNamespace>SampleTest</RootNamespace>
<AssemblyName>SampleTest</AssemblyName>
Rename their values into:
<RootNamespace>DocumentManager</RootNamespace>
<AssemblyName>DocumentManager</AssemblyName>`.
4. Build your project and you will see new DocumentManager.exe.config and new DocumentManager.exe files.
Or you can change Namespace and AssemblyName trough UI by navigating to Properties > Application > Assembly Name.

Automatically copying dll.config to a referenced projects output directory

I used the method suggested in the following post to include an App.config file to Class Library project.
Equivalent to 'app.config' for a library (DLL)
It works as mentioned and creates the .dll.config file in respective Class Library projects output directory (e.g. ApiCommunicator\bin\Debug).
I have referenced this Class Library project as a "Project Reference" from another Console Application project within the same Visual Studio solution.
Now the problem is, the .dll is getting copied to the Console Projects output directory (i.e. Engine\bin\Debug) but the .dll.config doesn't. If I manually copy it, everything works fine but is there a way to configure Visual Studio to auto copy .dll.config to any other project's output directory which references the Class Library project?
Thanks,
Bathiya

Although I am late, but my answer can help others. I used the following command as pre-build event:
copy /Y $(SolutionDir)\[YOUR_LIBRARY_PROJECT]\app.config $(ProjectDir)$(OutputPath)[YOUR_LIBRARY_NAME].dll.config
I tried to be dynamic as much as possible, and the above command worked.
I posted the same answer at the question Can we autocopy the *.dll.config? as well.

It would have to be the other way around: Projects referencing your dll could copy it's dll.config from a known location as a post-build event.
However I think it would be much better to provide the configuration from within the consumer application's configuration. That way each referencing project would have an option to adjust the configuration to its needs, which I would think is a critical feature.
If that is not the case, then I don't see the reason for having the .dll.config, and you can just hardcode the values.

You can use the 'Build Events' tab of your project properties to run command line instructions post-build or even pre-build. This way, you can use a simple
copy /Y "<yourconfigfilepath>" "<yourprojectfilepath>\Engine\bin\Debug\"
This will copy the dll.config file you are needing over to the correct directory.

Shared resources in a vsix template project

I created a solution with following structure
Solution
Installer (VSIX)
Template One (sdk project)
One.vstemplate
Template Two (sdk project)
Shared
AssemblyInfo.cs
Now I want to link the AssemblyInfo.cs in the shared project to my vstemplates, because i want the same AssemblyInfo.cs in all my projects.
I dont want to have sevaral copies because of possible future developments.
Till now i tried to add the AssemblyInfo.cs as link, but the template build process still search in the project folder and does not find the file (Add as link).
In addition i tried to reference the file using "\..\Shared", then i got a error out of root path.
One way I does not try is to use prebuild commands to copy the AssemblyInfo.cs to each project folder.
Has anybody an idea, tipp or solution for this situation?
I get a working version by using pre-build commands to copy the files from shared to the single templates.
Any other ideas how to solve this request?
Sorry for the late response.
I tried to reference the AssemblyInfo by adding following code to the vstemplate file
<ProjectItem ReplaceParameters="true" TargetFileName="Properties\AssemblyInfo.cs">..\Shared\AssemblyInfo.cs</ProjectItem>
My current solution is to add to each project a pre build command
copy /Y "$(ProjectDir)..\Shared\AssemblyInfo.cs" "$(ProjectDir)AssemblyInfo.cs"

Who copies app.config to app.exe.config?

I'm writing a game development IDE that creates and compiles .NET projects (which I've been working on for the past few years) and am in the process of updating it to generate output not only for Windows/Visual Studio, but also for Linux/MonoDevelop (a thrillingly simple process for .NET, but still requiring some tweaks).
As part of this, I have found it necessary to start generating an app.config file as part of this to map dependent DLL names to Linux dependency names with <dllmap> elements. I'm confused about who's responsible for copying the app.config file to the output name app.exe.config. In a Visual Studio project, the Build Action for app.config seems to normally be set to "None" and its settings indicate that it won't be copied anywhere, yet when Visual Studio compiles the project it generates app.exe.config (though I've sometimes found this to be unreliable). When I use MSBuild to build a solution file generated by the IDE (for debugging purposes), MSBuild copies app.config to app.exe.config. But when I compile the project with CSharpCodeProvider.CompileAssemblyFromFile it (naturally) doesn't like the config file being included as source code ("app.config(1,1) : error CS0116: A namespace does not directly contain members such as fields or methods"), and of course it doesn't copy it to the output when I don't include it as an input. Is it my responsibility to simply copy app.config to app.exe.config independently, or is there a more standard way of doing this?
Is it hardwired to take the first *.config file? In my IDE it's conceivable that the app.config file would be renamed or another one added (just as in Visual Studio). It seems odd to me that the IDE has this secret action for config files (I think MonoDevelop behaves similarly in this regard because I couldn't find a special action for config files there either). I don't know how it even picks to what files this secret action applies.

The C# compiler does not care about the config file at all. Build environments (MSBuild and VS) will take care of copying that file themselves.

Order:
first app.config file with None build action, in the project directory
first app.config file with Content build action, in the project directory
first app.config file with None build action, in a subdirectory
first app.config file with Content build action, in a subdirectory
msbuild/xbuild also allow you to override this by setting the $(AppConfig) property.

A slightly more technical answer - your project references Microsoft.CSharp.targets via this key in the csproj file:
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
This file would resolve to something like c:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets, depending on your framework version.
Inside of it you have this section which does the work:
<!--
============================================================
_CopyAppConfigFile
Copy the application config file.
============================================================
-->
<Target
Name="_CopyAppConfigFile"
Condition=" '#(AppConfigWithTargetPath)' != '' "
Inputs="#(AppConfigWithTargetPath)"
Outputs="#(AppConfigWithTargetPath->'$(OutDir)%(TargetPath)')">
<!--
Copy the application's .config file, if any.
Not using SkipUnchangedFiles="true" because the application may want to change
the app.config and not have an incremental build replace it.
-->
<Copy
SourceFiles="#(AppConfigWithTargetPath)"
DestinationFiles="#(AppConfigWithTargetPath->'$(OutDir)%(TargetPath)')"
OverwriteReadOnlyFiles="$(OverwriteReadOnlyFiles)"
Retries="$(CopyRetryCount)"
RetryDelayMilliseconds="$(CopyRetryDelayMilliseconds)"
UseHardlinksIfPossible="$(CreateHardLinksForAdditionalFilesIfPossible)"
>
<Output TaskParameter="DestinationFiles" ItemName="FileWrites"/>
</Copy>
</Target>
The App.Config file seems to be passed as an environment variable (it is expected to be present but who sets it, I don't know):
<ItemGroup>
<AppConfigWithTargetPath Include="$(AppConfig)" Condition="'$(AppConfig)'!=''">
<TargetPath>$(TargetFileName).config</TargetPath>
</AppConfigWithTargetPath>
</ItemGroup>
Edit: For how app.config is selected, see this answer - https://stackoverflow.com/a/40293508/492336.
The handling of app.config is special, it is treated By Name, the build process will select the app.config file following this order:
Choose the value $(AppConfig) set in the main project.
Choose #(None) App.Config in the same folder as the project.
Choose #(Content) App.Config in the same folder as the project.
Choose #(None) App.Config in any subfolder in the project.
Choose #(Content) App.Config in any subfolder in the project.

I think MSBuild is responsible for copying. If you would dig trough stock .target files, then you'd probably find corresponding directives. VS by itself doesn't copy.

Note also that Visual Studio does validate the config file.