I'm compiling C# code using CodeDom. Even when there are no resources specified, it still compiles a Win32Resource called "VERSIONINFO". I know I can remove it with BeginUpdateResource after it is compiled, but that will leave "PADDINGXXPADDINGXX" in the file, which I don't want. Is there a way to compile C# code to .exe without any resources?
Fretting about this is actually fairly troublesome. The EXE doesn't just contain the VERSIONINFO resource, it also has a manifest. Best way to see it is open the EXE in Visual Studio with File + Open + File. The manifest is under the RT_MANIFEST node.
It is important because it declares your program to be UAC compatible. Without it, Windows treats it like a legacy Windows app. Which some pretty unpredictable behavior, remapping file and registry access to isolated storage.
You can get what you want. Create an empty .rc text file in Notepad (not Visual Studio) and compile it with rc.exe to a .res file. Use /win32manifest in your CompilerOptions to force the compiler to use it so that it omits the auto-generated native resources.
Related
I want my program in Visual C# to allow the user to generate a portable .exe file to be run on another user's computer, with the portabe .exe receiving the values the first user inserted. I don`t want to use a configuration file or any other file to store the input values to be then read because I want the .exe to be a single file. I have the main and the second program (future portable executable)
as different projects on the same solution. Is there a way to modify values of the portable .exe or does a new program needs to be compiled on the fly?
To formally answer the question.
You can convert the assembly to IL, search and replace and recompile. However, if you are building this application, you should really consider the need and use case for such very thoroughly.
If you need just to modify the behavior of an application, you have a plethora of options.
Registry (can be remotely done)
A config file (though you ruled this out)
You could use a login method to a resouce
Wcf for instance
Active Directory
A network DB
Rebuild you app for these users
Msbuild with a batch file to tweak something
A pre build script
If you are really tricky you "might" be able to track down the offset of an int and tweak it. However this seems very unreliable
Or if you really have your heart set on this, see the following and associated questions
Modify Emdeded String in C# compiled exe
Is it possible to Add/Remove/Change an embedded resource in .NET DLL?
Update from Ben Voigt Comments
Win32 Resources can be changed after being embedded in an EXE. .NET
System.Resources can only be changed before embedding. C# applications
are compatible with both kinds, but the distinction is very important
The The necessary function is UpdateResource
You can typically append to an .exe without breaking it and then read the data in upon execution.
See: appending data to an exe
I'm trying this again, since yesterday my question drew no attention, and I'm guessing it was due to the lack of a well worded explanation.
When I build my WPF application, with the "Embed manifest with default settings" option checked, my AssemblyInfo.cs version info is embedded inside the output .EXE, and right-clicking the .EXE and checking properties shows that. I'm wondering how and at what point, does the compiler embed that data into my .EXE?
I ask because I recently had to create my own .res file to embed multiple icons into my .EXE with appropriate indexes. The problem with that is you need to select the "Resource File" instead of "Embed manifest with default settings option;" so you lose your AssemblyInfo version information and have to update and rebuild your .res file every time you do a release.
In short, I'm trying to find a way to compile my own .res file that uses my AssemblyInfo.cs version information and is automatically embedded for every build (my versions contain * definitions), so I don't have to worry about remembering to update my .rc and compile for the .res.
I have a installer app with a embedded .resx file with some information, like server name, port, password etc...
I have to generate this installer (this process is automated, and is done through our website) for each customer. This is working fine
I use ildasm for disassembler and replace the resx file, and then I use ilasm to make .exe again.
But after this process the .exe lost our icon, putting the default one in it's place.
I cannot find a way to change the default icon.
Thanks
You are missing out on a fairly obscure detail in a C# program. The executable the compiler generates also contains unmanaged resources. Required because Windows doesn't know anything about managed resources. This is something you can see with Visual Studio. Use File + Open + File and select a .exe generated by the C# compiler. RTM edition required, it doesn't work for Express.
You'll see at least 3 nodes for your program:
RT_MANIFEST contains the manifest for the executable. Very important on later Windows versions, it declares the program compatible with UAC. It prevents Windows from treating your program like an earlier Windows program that needs to be lied to when it does UAC verboten things like trying to write files to protected directories and trying to create registry keys in HKLM. The content of the manifest is a default one in most programs, you can get a custom one with the "Application Manifest File" project item template.
"Version" contains the version resource for the executable. It contains the info you see when you look at the properties of the executable with Windows Explorer. Its content is auto-generated from the [assembly:] attributes in your AssemblyInfo.cs source code file.
"Icon" contains the icon resource for your program. The one you don't have anymore.
You'll need to use the /resource option for ilasm.exe to embed those unmanaged resources into the patched executable. That requires a .res file, the compiled version of the unmanaged resources, produced by the rc.exe Windows SDK tool. Note how this is also exposed in the Project + Properties, Application tab, Resource file radio button.
You cannot ignore this requirement, you can live without the Icon resource but not the manifest, especially not in an installer program. Getting the .res file out of the original executable is going to be difficult, fairly sure that ildasm.exe doesn't support decompiling it. If a tool like Resource Hacker doesn't do it then you'll need to create a .res file for your program. Or review the wisdom of using ildasm.exe to do what you wanted to do.
broken to bare-bones scene:
I have a program in c# that calls a .exe inside cmd(using process.start), passing some required arguments.
What i'm trying to do: Include the exe into the project so that i don't have to call cmd.
Any idea?
If you just want to include so you don't have to ship two files then just include it into the project as "embedded resource" (see project item options) and then you can call ResourceManager.GetStream and write it to file and call Process.Start.
If you want integrate the functions of that exe so that the exe is not needed anymore (no Process.Start) then you need the source code...
EDIT:
the "write to file" is not necessary if the exe is .NET - then you can directly load it from the resource stream as Assembly/AppDomin and execute it.
You can add an exe as an embedded resource (just right click on a folder in the Solution explorer, Add Existing Item, then get properties on it and set it to be Embedded Resource). However, you may not be able to easily execute it in place - you'll need to save it to disk and then execute it (which doesn't solve your stated problem of having to ShellExecute the .exe file, but does solve the problem of having to ship more than one file to the end user).
If you have the source code, then you'll be able to repackage the exe as a dll, or integrate it directly into your program code.
If the exe is a .NET assembly, you could use ILMerge to merge the exe into your main assembly. You can then invoke the code in the exe directly.
why x86 folder exist in obj folder in c Sharp project file?
My project file structure is
ProjectOne
----------Bin
--------------Debug
--------------Release
----------Obj
--------------x86 //Why this?
-------------------Debug
-------------------Release
----- My source files.
Why my file current Directory is bin\debug, not projectOne (where my source file exists)?
When executing, the current directory will default to wherever the executable is - which will be in your bin/debug directory.
You can set where you want it to run from when you start it in Visual Studio though (in the project properties - if you need more details, please say exactly which version/edition of VS you're using).
As for the contents of the obj directory - you can pretty much ignore the whole directory. It's full of intermediate files that Visual Studio builds and then consumes - but you almost never need to use any files from there directly.
The x86 folder refers to the target platform for your build in your build configuration manager. It allows you to build 32 bit applications on a 64 bit OS. As Cody and Jon say you can ignore the obj directory.
The bin folder contains your application's binary files (that is, your executables). It is subdivided into two (or more) folders—typically Debug and Release. These correspond to your build configurations. When your project is compiled, the executable files are placed into one of these folders, depending on which type of build you conducted. If you want to run your executable outside of the development environment, you can click on the ".exe" file you find in one of these folders.
If you wish, you can change where Visual Studio outputs your executable files during a compile using your project's Properties window.
The obj directory contains intermediate (or object) files that Visual Studio builds when compiling your application. It's not really something you ever need to worry about or use the files from.
Finally, your source files are kept in the root directory, as displayed in your Solution Explorer window. You manage the locations of these files yourself; they are not managed by Visual Studio.
Object files (the files stored in Obj) are compiled binary files that haven't been linked. Think of it as fragments of the final executable that will later be combined to make your executable.
When compiling your source code each source file will loosely be compiled to one object file. Why? No reason*, just how your particular compiler was written. There are other compilers in other languages that does not do this but instead compile everything into a single large binary in one step. But the people who wrote your compiler decided to first compile to separate object files.
Now, you can imagine that if each source file generate one object file then every time you compile code your source directory will end up being messy and be filled with lots of .obj files (and indeed a lot of C compilers traditionally did this). Over time, developers working on large projects started to write compile script or configure their projects to collect all .obj files in a single directory to make the source directory less messy.
The people who wrote your compiler obviously liked the idea of a separate Obj directory so they made it the default configuration of projects. As for why there is an x86 subdirectory that's because your compiler also supports other CPUs like ARM (for Android, Win Phone 7 and iPhone) and also to differentiate between 32bit and 64bit.
* note: There are actually some very good reasons to do this including making the compiler code more modular and to support incremental compilation but the fact that some people can do all that without generating separate obj files mean that it is mostly a design decision by the developers of the compiler more than it being a necessity.