My solution has two projects: c++ dll and c# web.
Dll project has pre-built event like this
IF 2 == 1
(
echo ERROR: Dll building error
)
And, obviously, this condition not interrupts building process and it finishes with success, if I run it for dll project.
But..
the Web project depends on the dll and therefore uilds it, in turn, by MSBUILD.exe command in it own pre-build event. That is, as a result, pre-build parent (MSBUILD for web) following by nested pre-build childs (IF for dll).
. And if I try to build web project, it interrupts with message Dll building error (from the dll project pre-built event) after child dll project by MSBUILD.exe (in web pre-built event) has built with success!!! - result dll file has appeared in output dir!.
What it's means? Child pre-build event conditions incorrectly interrupts parent build process?
The problem appears to be that you're misusing MSBuild. The proper way to handle "subprojects" is to use a Solution. In this solution, you have both projects, and a project dependency from the web project on the DLL. You build the solution, and that's one MSBuild command. Therefore, the C# web project does not need to start another MSBuild command.
MSBuild, when using a solution file, sees the real dependencies and handles build failures correctly. Note that a "echo ERROR" in a pre-build event is just text on a screen, not a build failure. You'll need to exit /b 1 the pre-build step to stop the build
Related
I created a class library project and configured the properties section debug to start an exe (the.exe) located in the output directory of the build (as shown in the image).
It worked as long as we had a pre-build event copying the exe and all related files from one directory in the output directory of the build. Unfortunatly this is inconvinient and we do not have track which version of the exe is used.
So I created a versioned nuget package to place all the files in the output directory. I confirmed all the required files (I know of) are in the output directory. And since I created the nuget package manually with the CLI I can confirm they are exactly the same files.
But when I try to start the application from Visual Studio 2019 now I get the following error in the debug output:
The target process exited without raising a CoreCLR started event. Ensure that the target process is configured to use .NET Core. This may be expected if the target process did not run on .NET Core.
The program '[16616] the.exe' has exited with code -2147450749 (0x80008083).
Actually both (the.exe and the class library) are .NET 5.
Comparing the changes of the two setups via Git changes does not hold any clues beside adding the nuget and removing the pre-build events.
So any clue what could be the difference/problem and how to get the executable running? May I missed something?
Well, better check twice when you are stating "I confirmed all the required files (I know of) are in the output directory."
The problem was that not all files made it into the output directory.
In my case only the the.exe and the.dll were placed into the output directory. Once I checked again and ensured that also the.runtimeconfig.json (which was missing) were added it was running again and the exception were gone. Though I am not sure if there is a better way than distributing the.runtimeconfig.json.
update visual studio using Visual Studio installer worked for me. This link! helped for me.
I've got an C# Project in Visual Studio, which has Console Application as Output Type.
But I also need a Class Library of this project for another solution.
Right now I have to switch the output type every time, but I wonder if it's possible to generate exe and dll at the same build-event?
Is there a post-build-event for this?
To my knowledge there is no possibility to change the output type after compilation. That being said, if would be possible to have two projects like Console and Library in your solution, which would use the same source code files but have different output types. That way you would have different outputs without any duplication of code.
it is generally possible to reference a .net exe assembly as it would be a class-library.
So you can just stick in creating an exe file and reference the exe (sounds strange, but works) in your other project.
This is the dialog for browsing for references. As you see you can select exe files.
But as commented it really depends on what your usecase is.
I don't recommend to ship an exe with an entry point to your customer hoping that the customer does not discover the exe. But what you could do about that is to conditionaly compile your entry point.
For example
class Program {
// This is the entry point of the EXE
public static void Main() {
#if DEBUG
// Start Debug Application
...
#else
// Shipped to client - Entry point disabled
return;
#endif
}
}
If there is a relevant reason to have a shipped exe and a shipped class library, I would refactor your solution like this:
(A) complete application (.sln)
(B) console-application (.csproj) which has a reference to (C)
(C) class library project (.csproj)
With that it is perfectly clear to others that there is an application that uses the library and the library itself.
Console Application is the type of your project. You can not change it.
What you can -and must- do is, carry your logic into a Class Library project and use your class library from any type of project you want.
You should compile your project to become a dll and then use this dll in a console application.
A possibility to achieve what you want is to manually run the msbuild on your post-build event of your project.
See: How do i build a solution programatically in C#?
or Building C# Solution in Release mode using MsBuild.exe
The usual solution for this is using a Solution with two projects:
a Class Library with all the code (which builds into a DLL)
an Console Application referencing the library whose Main just calls some function(s).
For more information, check the MSDN page on Solutions.
Codor suggested manually adding the files to the Console project, but one downside is that build settings are not shared between both versions, so you might get some inconsistency there.
I'm not really sure why people think it's not possible but it actually is.
The easiest way would be renaming the exe to dll Sounds stupid, I know. But it works in many cases. Also, as "Peter I" said a .NET exe can be imported as assembly in other projects. So you might not actually need a dll anyways.
Another way would be using C# command line as stated here: /out (C# Compiler Options)
You can use command command line options in Pre/Post build events Pre-build Event/Post-build Event Command Line Dialog Box
I have a similar requirement and couldn't find any definite answer in this post or anywhere. I currently have a class library and would like to create a console application project without copying any code. Ideally speaking there should be two projects, one for creating a console application and another for creating a class library. And this is what the visual studio also suggests. When I tried to run the class library, I got the below message.
It clearly asks us to add an executable project to the solution and add the reference to the library project.
Below are the steps to do this.
Right click solution -> Add new project -> Console App -> choose name -> ok.
Right click on the console project -> add reference -> In reference manager, click on the projects tab and select the other project(In my case this is the class library project, In case it is not listed just click on browse and select the .csproj file) -> ok.
Now to use the classes in the other project, simple do using LibraryProjectNameSpace
There we are. Bingo!!!!
Also as mentioned in the other answers it is not possible to have the same project generate both .exe and .dll. But you can have the same solution generate these two guys by having two projects. In this way there is no need to switch the output of the project every time.
FYI, I use visual studio 2017
I'm writing a .dll using Monodevelop on Linux that is run by an application, and I have no control over how or when my code is called, but I would like to debug that DLL.
How can I make Monodevelop's debugger attach to that DLL when a chosen method is run in the DLL ?
Alternatively, I thought about starting the debugger from the code itself (i.e. "from now on, please debug me").
The DLL I'm writing contains a xbuild task that throws and obscure exception when run using xbuild (but the code runs fine if I call it from main), so if there's any way to debug custom xbuild tasks, I'm interested in that too.
Open your library project options
On left side go to Build->Output
Output path: set to path where external application will load your dll
On left side go to Run->Custom Commands
In dropdown box with text (Select a project operation) change to "Execute"
In Command textbox set to external executable that loads your dll
Now you can right click on your library project in SoltuionPad and set "Set As Startup Project"
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 have a project in c# which uses bindings to use some c++ code. The c++ code consists of multiple DLL's which are compiled using a makefile. Currently I'm trying to run the makefile using a pre build event which calls nmake. However to get it to find nmake I need to have a line in it like the following:
"$(DevEnvDir)..\..\VC\vcvarsall.bat"
Also, even with that line present, nmake doesn't produce any output at all in the output window. Neither does it throw any errors. I tried redirecting the output to a file and it doesn't write anything. I have reproduced all steps in my pre build event in a normal shell and it works fine. I figure I must be missing something. Why doesn't Visual Studio give me a Visual Studio shell for my pre build event? Is there a better way to run this makefile? If not, has anyone got any ideas as to why nmake isn't producing any output?
EDIT: D'oh! nmake wasn't running as I forgot to add 'call' to the start of the line, i.e:
call "$(DevEnvDir)..\..\VC\vcvarsall.bat"
I often build non VS-project (sometimes with nmake, sometimes with other build tools) as a part of a larger solution build.
I tend to make a simple batch file, which sets up the environment and then runs the make.
I call the batch file from a build event (often post-build on my stuff) - usually with a CD on the front:
cd ..\.. && armbuild
Never (that I can remember, anyway) had any problem with the output appearing in the console window.