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"
Related
I know this can be done via Visual Studio. But I wanted to know if there is a command or a workaround to add folders to a project.
My projects are: Class Libraries a project for creating a class library that targets .NET or .NET Standard
I tried with a shell script:
mkdir DTOs;
mkdir Behavior;
mkdir Features;
mkdir Filters;
mkdir Interfaces;
mkdir Mappings;
mkdir Wrappers;
folders are created but they are not added to project.
Thanks in advance.
Please check out the following detailed answer by poke.
Paraphrasing it for reference here:
Project folders
In modern .NET Core projects (using the .NET SDK), files are automatically added based on a global file pattern. For example, any .cs file anywhere within your project directory is by default automatically configured to be a part of your project that needs to be compiled. This pattern however only applies to files, not directories.
Directories are not an explicit part of a project by default. Instead, they are only there if they are “needed” for a path to a file. That’s why you won’t see folders within Visual Studio until there is a file that is part of the project.
If you are within your project folder and then add a folder there, you will not see the folder there. But as soon as you add a file to that folder (echo '' > TempFolder\Test.cs), it should automatically be picked up by Visual Studio:
You can also enable the “Show all files“ option in the solution explorer, to make folders that are not part of the project appear in the solution folder:
As you can see, the folder appears as a transparent item because it is not part of the project itself. You can then right click on the item and choose “Include In Project“ to make this folder an explicit part of the project. This action will add the following section to the project file:
<ItemGroup>
<Folder Include="TempFolder\" />
</ItemGroup>
This basically tells Visual Studio that the folder is part of the project even though it does not contain any files. As soon as you do add any file to the folder, Visual Studio will remove that configuration though since the folder is now again an implicit part of the project.
Solution folders
Visual Studio solutions don’t show the actual directories within your solution directory but rather a virtual directory as configured within the .sln file. Projects being located within subdirectories will not automatically be located within such a folder within the solution structure, and similarly non-project folders will also need to be added to the solution file first.
There is no mechanism to manage the solution folders with the dotnet sln command though. The only thing that you can do is add a project into a particular virtual folder within the solution:
dotnet sln add path/to/project.csproj --solution-folder VirtualFolder
This would add the project.csproj inside the VirtualFolder solution folder within the Visual Studio solution.
If you want to manage the solution folders otherwise, you should do that with Visual Studio.
BACKGROUND
I'm mostly programming in embedded C/C++ but sometimes I have to do some C# programming for our API. For this I'm using Visual Studio 2017 to create an API DLL for our customers.
The C# API and our C/C++ firmware are using a common set of status codes. I have a Lua script that generates these codes to a .h (for C/C++) and a .cs (for C#) file so they always are in sync.
All source files that are shared across products and platforms are in a special project called "Common" (checked-in to Subversion).
When we create new projects and use any "common" file, we put them in a sub folder called "Common\" so we know that there is no point in messing with them. Subversion will check out these "Common" files as externals of a specific revision used by each project.
In C/C++ it's no problem at all to have source code organized in several levels of folders, all source files have a relative path to the root project folder.
THE PROBLEM
So in this C# project I organize the source code as usual:
ProjectRoot\source.cs
ProjectRoot\Common\EStatusCodes.cs
In the ProjectRoot\ we have all .cs files for this C# project, and in ProjectRoot\Common\ are the external files from subversion's "Common" project.
So after the checkout of the external EStatusCodes.cs into the ProjectRoot\Common\ folder I add it to the C# project by "Add->Add Existing..." and then I point out the ProjectRoot\Common\EStatusCodes.cs file.
The file shows up in the Project but for some reason Visual Studio has COPIED the file form the ProjectRoot\Common folder to the ProjectRoot\ folder and is then using the copy! (The file's path in properties is set to the ProjectRoot\ folder.
So If we add more status codes to the "Common" project, this C# project don't get the update because Visual Studio now always use the copied version of the file from ProjectRoot\ and don't care if ProjectRoot\Common\EStatusCodes.cs has been updated.
I tried to add the Common folder to "Properties->Reference Path", but it still copies the file every time I add it to the project.
Is it possible at all to have source files somewhere else than in the C# project's root folder?
In the Add Existing dialog, there should be a small down arrow next to the Add button. If you click this, you'll see an option to "Add As Link". This will add the file as a reference link to the original file and any changes to the original will reflect in your project.
We have a similar way in C# project: add existing file to project as "Add as link".
Please refer this link for more details:
https://grantwinney.com/visual-studio-add-file-as-link/
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.
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.
The nlog.config is being put into the bin/Debug for my project. In the setup project I have primary output of project a and content files of project a to be included in the Application folder. nlog.config, however is not making to the msi. Any ideas?
Adding the file manually means that you will have to redo the step if you change the file in the source.
Instead, make sure that the build action of your NLog.Config is set to "Content"
Then, add Project Output Group of type "Content Files" in your setup project:
.
I have found a solution to this. Right click on the setup project and choose Add then File. Just select the nlog.config file from the bin directory where it is being placed after a compile and it works perfectly.