How to output the generated MSIL code in a separate file? I know there was an compiler option, because I used it (I think in VS2012) for a short time, but I cannot find this option anymore, I cannot even find this option in the compiler options list.
To my knowledge, the only way you can create an IL file of your assemblies is to add Post-build events that will execute when the build is successful.
In VS, you can do this by going to opening Project properties screen, and going to the Build Events tab.
From there, just set a Post-build event, similar to the one below. Please note, I had to add the reference path of the ildasm.exe application to my Windows PATH environment variable. If you have to do the same, this will require a log out and back in, for it to work.
Related
I have created a small program in C# WinForms that runs fine when I start it in Visual Studio 2017. But when I build the solution and double click the .exe, nothing happens, no screen appears, even the task manager doesn't see it. No errors. It's like it doesn't do anything! My only guess is that I built it wrong because I used Nuget to install newtonsofts JSON.NET in the solution. Do I need to do anything differently or should just building the solution work?
[solved]
today i learned the difference between the bin and obj folder, thanks to everyone for helping
Based on your comment:
it is in the obj/debug folder of the project
It sounds like you're running the wrong .exe. The obj folder is used for temporary/misc. files from the build process (see What is obj folder generated for?).
Instead, you want to run the exe within bin\Debug, if "Debug" is the configuration you're building for. You can see which configuration at the top of VS.
Like others have also mentioned, make sure that Newtonsoft.Json.dll is being copied to that output directory as well. Programs and their dependencies need to be together, generally speaking. Otherwise, your exe will not know where to find the JSON code it needs to function.
99% of the time, you should pretend the obj directory isn't even there.
If that still isn't pointing you in the right direction, run the app from a command window. Any exception should get printed to it and the window will remain open for you to examine (and this has the benefit of not needing any additional logging or exception handling code to see this error).
For example, I wrote up a bad application that get a NullReferenceException in a method called Test that is called from Main. As you can see, the stacktrace is easily visible, even though my app has crashed (credit to ColinM for bringing this up originally).
I believe that there's a problem with the startup module. Follow the steps below
Open your Solution in visual studio
Double click on properties
Select output type to Windows Application
Make sure to set the startup object as follows
I hope it helps
I think there is only one reason
There is a command line argument predefined in Visual Studio. Your application uses this argument to be executed, without it, it closes itself too quickly and you even can't see your application opened.
Right click on your project in VS -> Properties -> Debug and see if there is a value in command line arguments
exe and their supporting files should be in the bin folder. Do not copy only exe from bin folder and try to run it. It is a good idea to write some exception code to get the detail.
For future reference, yet another reason (that I have experienced) can be
System.Diagnostics.Debug.Assert();
statements. In my case, the program executed normally when started from VS but when I run it by clicking its .exe (created in the Debug Mode) then it hung/freezed. No exceptions, no printed logs. Frustrating. Then I checked the Windows Event Viewer (Our true friend). It explicitly displayed the problem and the culprit was a Debug.Assert() statement.
The lesson learned again: Check
Windows Event Viewer > Windows Logs > Application
especially when your app hangs/freezes/deadlocks or when no app logs are available.
So in VS, I create a project, right? Let's say I'm following a tutorial that has extra code that I don't need that only serves to show examples for looping, threads, etc. - then moves onto the real code. I take notes of everything so I usually save a copy of my source code with a different name as future notes. Now the only thing with projects in VS or any other C# compiler is that if you save the file AS "..." or make a new file, sometimes I find that the compiler will now compile the new code or the old code (it gets me so mixed up).
I get why it does this though, to link to other sourcefiles right? Well anyway, all I want to know is how do I compile a different C# file within my project folder? I don't want to create a new project, it just makes it harder for me to organize.
Assuming you want to include a lot of files into project bu only compile one you can just change "Build action" to "none" from "compile" for CS files you don't want to build.
I am working on a project and while compiling, my laptop handed up and I have to turn it off manually.
After the restart I found that my code is not showing up. There is no line of code in program.cs file.
I am working on that code since a month. And all of it vanished.
Need help. I have the executable file working properly. But i need the code. Is there any way to find that code ?
Use ILSpy to decompile your executable. You will get the source code back, minus the comments. This is possible because assemblies (like your exe) actually contain "Intermediate Language" (IL), and not native machine code/assembler. From the IL it is possible to get a reasonable representation of the original source code. You may need to recreate the csproj file manually, if you do not have it.
If you have the .exe you must have compiled it, if you compiled it you must have saved it.
Where it is depends on where you saved it. Easiest thing would be to use the search function in Windows – search for whatever you called your program, or failing that, *.csproj. Then you can open the csproj file with Visual Studio and you should get most of it back.
I have a custom script language and a compiler (an EXE written in C) that turns that language in to C# code. I'd like to hook up the script compiler as a Custom Tool on script files in the solution, and have it generate C# code behind.
I've seen articles and tutorials online, and they all have you generate COM interfaces and register your custom DLL with the registry and GAC, and I really don't want to deal with all that.
Is there a wrapper or hack or 3rd party plugin somewhere that would make this easier? Like if there was a way to run a batch script as the custom tool, and have the code behind file get generated from the stdout of that, I could pipe the file from my compiler to stdout.
First off, I know you said you don't want to register through the MSFT way, but I suggest you reconsider. Details are here: http://msdn.microsoft.com/en-us/library/vstudio/bb166527.aspx
Now that we got that out of the way, my suggestion to you:
Put your exe in a fixed location (best spot is probably right in the root of your solution or repository). Next, run your tool manually once, this way you have the .cs files or whatever you are generating so you can add them to your solution. That way the C# compiler knows they are there and you just have to hit the build button and it'll have the files to build.
Next, create a pre-build event (under project properties, build events tab) that calls your exe with the appropriate command line arguments to make it do its thing (generate your new cs files). I suggest you edit your exe to take multiple files at a time, to make your pre-build command more simple. (This is where placing your file in the sln or repo directory is helpful, because you can use VS macros to get an absolute path to both your exe and the files to read in.)
What happens now, is before msbuild gets called (but after you hit build) your script (or exe) will run to generate new output files. Since msbuild hasn't started yet you can change any solution files to your hearts content and the changes will be picked up by both msbuild and eventually (probably once the build is complete) VS.
Notes:
I have never been able to get a build event to work on the first try, it usually throws an error that will show up in the VS error/warnings window. I usually copy the whole error into notepad (or scite) and edit it down to the actual command line with arguments. I then open up a command shell and try to execute it. The errors here are usually more helpful and you can tweak until you get it right and copy the changes back in to VS.
I am using VS.NET to attach to a process, the process has a lot of DLL loaded, I built one of the DLL and try to set a breakpoint inside my DLL. I click "New Breakpoint" and type my function name Func_A and checked the "Use Intellisense to verify" box. Then I click OK but the VS.net complains that it can't find the function.
When the process is attached I checked the output of VS.NET, it didn't has a "can't load symbol" message behind my DLL line, so I think it has successfully located my PDB file. I don't know why I can't set the break point.
My project is C# managed project. Note that for all the DLLs, some has debug informations, some don't, but I believe VS.Net has identified my debug informations.
Please suggest other ways to try...
Another question is is there any tool to see the functions that can set breakpoint in an assembly DLL file?
If you see a lot of DLLs loaded then it is likely that you are running the debugger in native mode. It is an option in the Tools + Attach to Process dialog, be sure to pick Managed.
By far the easiest way to avoid trouble like this is to load the source code file and set the breakpoint by clicking in the left rail of the editor window. Also, don't use Attach to Process. Use Project + Properties, Debug tab, select "Start external program" and select the .exe that loads your assembly. You can now start debugging by simply pressing F5. Beware that this option is not available in the Express edition.
Could do with some more details really, but here goes...
Do you have the source for the DLL? If so, just open the code and add the breakpoint wherever you want.
If you don't, then you're pretty much relying on Intellisense which isn't always reliable I've found, particularly if managed C++ assemblies are involved. To help, you could look at the DLLs using Reflector to get the full namespaced function name and try that, ignoring Intellisense.
Using reflector will also let you see if the DLL is obfuscated (if 3rd party).
Hope this helps give you some new ideas of how to tackle it.
K