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.
Related
We have one master project that creates a single DLL with FEATURE_1, FEATURE_2 and FEATURE_3 as three conditional compilation symbols that enable those respective features.
MyLib.dll => has FEATURE_1, FEATURE_2 and FEATURE_3 compiled in
We now wish to have the same master project spit out 3 different DLLs as follows:
MyLib.1.dll => has only FEATURE_1 compiled in
MyLib.2.dll => has only FEATURE_2 compiled in
MyLib.3.dll => has only FEATURE_3 compiled in
At present we build within VS2013 and those compile constants are defined inside the .csproj file (within the <DefineConstants> </DefineConstants> tags), which hard-codes them.
Is it possible to pass them via a command line so we can still maintain one master csproj but build the 3 different flavors in the RELEASE configuration just by changing the command line (eg: gcc's -D<buildFlag> style) ? The solution has other projects and they're designed to work with the RELEASE configuration. I'm also open to any other technique that is easy to use and maintain.
We're really trying to avoid creating pseudo-projects or affecting other projects in the solution (21 projects in the solution) - seems like an overkill/hackish for something very simple.
I haven't done anything with the command line, but to solve similar problems, I created separate projects (that define the Framework Target and any conditional compilation symbols), and then add all the project files as LINKED files. In this way, I only have to modify a single set of source files, but each project compiles into its own DLL.
To add a file to a project as a linked
Right click the project and click Add Existing Item...
Select the file (or files) you want to Add.
Instead Of clicking the Add button, click the arrow next to the Add button, and click Add as Link.
I'm not sure if this will work for your case, but it sure has saved me lots of time when developing libraries for different .NET framework versions.
Is it possible that you have a complete turnaround?
Instead of defining all features in a single library and then disable some of them, you can create individual projects for each features, and then at packaging phase merge the smaller assemblies into a single one.
Microsoft has ILMerge, while ILRepack is an open source alternative,
https://www.nuget.org/packages/ilmerge
https://www.nuget.org/packages/ILRepack/
Then you are free of conditional compilation, which is too difficult to manage, and the complexity is moved to your packaging scripts, which can be easily managed and checked into source code management.
I have an exe file for my application using visual c#.
Whenever I have to change, I go to visual studio, change or add the code and build the application.
So that my exe file will be updated.
Now what I want to do is I just want to add new changes c# script to exe directly.
I don't want to build the application from visual studio again and again whenever I have to change the code in application.
Because sometimes it's take too long to build for big application.
Is there any tools or way to do it?
Thanks.
Uhm no.
The most you can do is avoid visual studio, edit the source files using a lightweight editor, and re-compile the assembly using msbuild (e.g., msbuild.exe mysolution.sln).
If your project is large, building it can take some time. If you only need to change a small portion, you should seperate your project into smaller assemblies so your change in one assembly does not force a rebuild of your whole infrastructure.
If we're talking purely about building a project outside of visual studio then use an MSBuild scipt.
There is a decent tutorial here: http://goo.gl/MOseG
Note that you can reference static assemblies if you only want that project to be built, but be aware of stale references!
Now, let's have a look at the source of a your problem, large build that take a long time. I susggest you read here:
http://msdn.microsoft.com/en-us/library/ee817674.aspx
It may be wise to split you solution into several sub solutions.
Well you could seperate that file which you change often into an own assembly and just rebuild that assembly. Of course you need to make an reference to that assembly in your application.
Have you tried commandline compiling? It can be faster then Vs cause you dont have to open Vs (if you changed you code in notepad for example). Otherwise it nearly takes the same time (or longer cause you have to type in paths).
csc /out:YournewExe.exe YourFile.cs
Csc is the c# compiler and can be found at C:\Windows\Microsoft.NET\Framework\Version
Further information can be found here Click
Why don't you just save your project file everytime instead of building it? And when you finish working on it for today,just build the app then.
You don't have to test the app everytime through the .exe file,do you?
I'm trying to create post build events to copy the final .js and .debug.js files for my script# projects into the proper directories. I can't use the regular output folder, since I have more than one project that references another project, and that always results in a build error (Unable to copy referenced script because it is being used by another process).
The problem is that the C# compiler appears to run the post build events BEFORE it writes the actual .js files, so they don't exist when the post build event happens.
Is there any other solution to make this work?
You can set up a DeploymentPath property in your csproj and the generated scripts will be copied there.
All of the logic is in here: https://github.com/nikhilk/scriptsharp/blob/cc/src/Core/Build/Tasks/ScriptCompilerTask.cs ... so another option is to customize the build task to exactly your requirements.
The latest work if you check out the github repo, also has the script# part of the build process done during the build step of an msbuild project, so that should free up the post-build step for you to do what you'd like with the generated scripts. See https://github.com/nikhilk/scriptsharp/blob/cc/src/Core/Build/ScriptSharp.targets. Again, its just msbuild stuff, so you could potentially customize the .targets file to your liking as well if it doesn't fit your needs.
I got around this by adding the "copy" command as a pre build step on the projects that were using the script# project output, then adding a dependency so that the script# project would be built first.
I am writing a utility for my company that will batch build a number of solutions in a one-click fashion. There are about 8 solutions in all, and each one has an average of 20 projects. The utility needs to be able to capture the build log and the total number of errors for each solution, just as is done when you build at the command line. I know I this is the command to accomplish that
msbuild mysolution.sln /t:build /verbosity:minimal /maxcpucount:xx
However, I would like to make use of the Microsoft.Build.Evaluation API's if possible. I know the Project object can load a single project, but is there anyway to build an entire solution? I intend to build this utility to make use of the all cpus/cores on the system and build multiple solutions simultaneously. I've looked at the MSDN page for Microsoft.Build.Evaluation, though the documentation is (still) abysmal.
Thanks for any help you can offer!
Jason
You do not need a Visual Studio solution file (sln) to build multiple projects. As you may know, Visual Studio project files are just MSBuild XML files and they can fall other project files. Therefore, build a project file that builds the other projects as required. This can be done in one of two ways.
First, solution files are just MSBuild XML so anything that can generate XML can generate a solution. See the MSBuild XML Schema for more information.
Second, construct a Microsoft.Build.Evaluation.Project programmatically using the constructor that takes an Microsoft.Build.Construction.ProjectRootElement instance then call Project.Build(). The ProjectRootElement has methods for adding common element types such as CreateTaskElement(), CreatePropertyElement() and CreateTargetElement().
See also:
Replace .sln with MSBuild and wrap contained projects into targets
Generating an MSBUILD project file from a visual studio solution file and project files.
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.