I am trying to replace a Resource of an exe (.NET, C#) file using C# code.
I have found this article and made this code (using Mono.Cecil 0.6):
AssemblyDefinition asdDefinition = AssemblyFactory.GetAssembly("C:\\File.exe");
EmbeddedResource erTemp = new EmbeddedResource("encFile", ManifestResourceAttributes.Public);
erTemp.Data = myNewFileBytes;
asdDefinition.MainModule.Resources.RemoveAt(0);
asdDefinition.MainModule.Resources.Add(erTemp);
AssemblyFactory.SaveAssembly(asdDefinition, "C:\\newFile.exe");
The code is actually removing the resource and then adding a new one with the same name.
The resource name is encFile and stored as encFile.exe (tried both).
I tested the code and the remove is working (i can tell by the size of the file) and the adding too, but the new file crash just like the file i created with the remove only (for the testing) - it acts like he can't see the replaced resource.
What can i do to fix it? Maybe some changes in the edited EXE file?
The EXE file reads its resource this way:
byte[] buffer = ProjectName.Properties.Resources.encFile;
Trying to do this seems overly complex. If you need dynamic update of resources, ship your resources as a folder for your application (set items in the folder as content and copy if newer in project properties).
If you need dynamic update at runtime, then it's as simple as either:
1] Allow user to replace items in place or
2] Even better, treat it like word-press themes and allow an override folder for each resource.
If you need to tag each resource with metadata you could use a sqlite database or even easier, allow a matching .meta file for each resource to describe it in more detail.
Finally, if you are allowing digital download of your software, then you might consider code-signing your executable - in which case modifying the executable in any way will not be an option.
Related
My app has been designed to be able to run on two different languages, english and czech. In order to accomplish this, I've created 2 resource files:
If an end-user would like to add another language, for example GlobalStrings.fr-FR.resx, is it possible to allow for this functionality without rebuilding the application?
If we look at the properties of these resource files:
I'm not understanding what embedded resource means. Does this mean that in order for the app to consume this file, the application must be rebuilt?
How do we create a resource file, that is open to be extended/changed by the end user, without having to rebuild the entire application
?
Regular .Net resources are compiled into assembly with particular name and loaded by matching that name. So if "end-user" is ok to translate strings in resx file and compile resources into assembly with particular name (like "MyResources.cs-cz.dll") you can do that with default .Net behavior without recompiling main code. See MSDN:Packing and Deploying resources and related links for more information.
Note that you don't need Visual Studio for it and can use csc command line compiler to embed resources on user's machine - so if your really want you can provide simple script that compiles corresponding resx locally. Note that editing XML (resx) as text is generally not possible by regular person due to required encoding of some characters - consider technical level of your "end-users" before going that route. Plain text version of source for resource may work in more cases.
Usually this is not the case - if end-user localization is requirement you would create some sort of custom resource string management by loading strings from plain text files or database that users can update locally.
I've seen a number of variations on this question and im not sure if this question has been completely duplicated.
I would like to be able to at run-time run an existing executable (SOURCE exe) and have it:
1) take an existing TARGET exe at run time and add content of any size and type to the TARGET exe (pdf, image, word, excel file type, etc)
2) be able to run the modified TARGET exe so that when the TARGET exe is run, it will find the embedded content inside of itself and copy the content to the hard drive and then run the program associated with the content (foe example, run excel on a copied xls file)
I've seen examples where you embed resources at compile time in visual studio but I want to do this at run-time in code (c#, java, whatever works). Either the host TARGET exe needs to already exist and content should be added to it OR the exe will need to be generated from scratch at run-time and content again added to it.
I also would prefer not to use any of the cmd-line tools that visual studio or any other tool would run behind the scenes (if possible) to create an exe to minimize the enduser needing to download any more libraries/sdks than necessary.
This product is in line with what i want to do
http://www.boomeranglistbuilder.com/instructions/usingsoftware.php
(I want to improve upon it) :)
Lastly it'd be great if the solution could be cross platform compatible (doubt it though)
Could this be done in java?
I've seen the window library resource method updateresource method mentioned in my searches but I'm not sure if that would completely fit my situation. can anyone comment?
I hope my question is clear. Please let me know.
Any help would be graciously appreciated.
Thank you,
Carlos
I think that it's true for most binary file formats (including the executables), appending data to a well-formed file will not affect the usage of the file, the way it is typically interpreted by most programs. You could, maybe, take advantage of this.
To embed, you'll need to take your (existing) target executable and simply append some binary data to it. That data will have two parts:
A magic word (to denote the presence of an appended resource)
The resource itself.
So, this:
[target executable data]
Becomes this:
[target executable data]
[magic word]
[resource]
To read the resource from the target executable, simply have that executable open itself, search for the magic word and, if it's present, start reading the resource appended after it.
This is what WinRAR does (or at least did four years ago, when I last checked) to recognize the archives inside of its self-extracting files.
I'd like a user to download an exe from my website, where (synchronously upon download) an XML file is injected into this application. This XML file contains a public key, and a signature.
How do I inject the file prior to downloading and reference it later during execution?
Ideally I won't be using a shell to inject the file, rather a native .NET api.
You could that easily with Mono.Cecil, you'd just have to write something like:
var module = ModuleDefinition.ReadModule ("Application.exe");
module.Resources.Add (
new EmbeddedResource (
"signature.xml",
ManifestResourceAttributes.Private,
File.ReadAllBytes ("signature.xml")));
module.Write ("Application.exe",
new WriterParameters {
StrongNameKeyPair = new StrongNameKeyPair ("keypair.snk")
});
To inject the signature.xml resource from the signature.xml file, and sign back your assembly with your keypair.snk that you used to sign Application.exe.
And at runtime, you'd just have to use:
var stream = Assembly.GetExecutingAssembly ()
.GetManifestResourceStream ("signature.xml");
To retrieve the resource.
To inject the file add it to your project. Then right-click on it in the solution explorer, go to properties, and change its type to EmbeddedResource.
To load it at run-time use Assembly.GetManifestResourceStream(). Read more here: http://msdn.microsoft.com/en-us/library/xc4235zt.aspx.
From what he writes it seems he's gonna dynamically change the file prior to download.
This really depends on the server-side language you use, And how much control you have over your server/hosting provider account.
Say you have a download.aspx file which generates this exe files and sends for download.
One thing you can do is to put the assembly's source on your server then download.aspx assembles it and send it for download. (The difficult way)
Another way is to put the compiled assembly on server then use e.g cecil ( Programmically embed resources in a .NET assembly ) or whatever to change it then send it for download.
This google result seems promising.
Add the file to your project, typically something along the lines of:
+solution
+project
+Resources
+SomeDirectory
-SomeFile
Then go to your project's properties, go to the resources tab on the left site and select the files resource on the top nav bar. Select to add a resource > add existing file. Browse to the file you just put into your project and select to add it.
The file will now show up under your Resources tab of your project's properties. Change the name of your file in the Resources tab to be more meaningful.
The file is now an embedded resource of your project and you can access it by the following in code:
var MyFile = Properties.Resources.MyFile
Application is a C# .Net 3.5 WCF Service.
I'd like during the build process to dynamically add some build information to the final binary and assemblies that can then be read programatically and sent back to the WCF client when it sends a GetVersionInfo request to the web service.
.Net assembly versioning isn't enough. I want to include additional string data that contains the state of the system at the time the application was built.
I'm thinking that I'd do this by adding a post build event to call a script to update the app.config file with the data I want. Does this sound about right, or should I be considering some other approach?
Update
I'd additionally like this string to appear in the "Special Build Description" property of the final exe. I.e. I'd like to right click on the file and see this information in the version tab for the file.
Thanks in advance.
I suspect a pre-build event may be more appropriate than post-build... have you considered adding a buildinfo.xml file (or similar) to be built into the assembly as an embedded resource? You could then load it with Assembly.GetManifestResourceStream. That way you don't need to worry about fitting in with existing files or anything like that - just overwrite buildinfo.xml with a new file in the pre-build step.
You have to decide how important it is that the information you want to exchange is tied to the executable file itself.
Updating the config file during the built is a workable model, but it places the information in a location where it could be altered by anyone with access and a text editor.
Updating information after a build in a compiled assembly is certainly possible, but it's fragile and breaks down if you ever decide to sign the assemblies. It's also a lot of work, since there's no built it support for re-writing assembly files in this manner.
An alternative you should consider, is creating your own custom assembly-level metadata attributes and assigning them during the build process. You could even place them in a separate code file (or append them to AssemblyInfo.cs) as part of you build.
You could also consider creating an embedded resource (an XML file, for instance), and retrieving it from the assembly manifest at runtime.
Either of the above approaches would require you to use a pre-build custom step rather than a post-build step.
Personally, I find the metadata attributes a convenient approach if there isn't a lot of data. Otherwise, I would consider using an embedded resource file.
does somebody know how can I embedd an exe file into a dll ?
I have a tool which is an exe file that I call from c# code.
The thing is that I want to have 1 dll containing this tool (exe file) and the dll containg my c# code.
Is it possible to embedd this exe file within the resources?
Thx in advance
Sure it is. You can add any file as RC_DATA in application as resource. But I believe you will need to extract it to disk first before calling it!
Which IDE/Language you are using?
[EDIT]
Sorry! you did mention that you are using C#.
Add a resource file to you application (right click application in IDE and select "Add new item".
Use the toolbar in resource editor to add an existing file.
Then extract the exe whenever required by calling code something like:
System.IO.File.WriteAllBytes (#"C:\MyEXE\", Resource1.MyEXE);
It's worth baring in mind that your uses may not be too happy about you doing this. Embedding an executable that they've got no control over into a DLL that you'll extract and run will probably make people worry about the running a Trojan on their machine.
It's better to leave the .EXE in the filesystem and be transparent about what your application is doing.
You can load an Assembly from a byte[]. This can be obtained via the ManifestResourceStream of an embedded resource.
An alternative may be to not embed the .exe itself, but rather include its functionality in the dll, and use rundll32[1] to execute it.
On a side note, remember that when you pull a file from your resources to disk and then execute code on it, you may trigger Windows Data Execution Prevention - basically, Windows tries to automatically detect if something is supposed to be code or data, and if it looks like data (which a resource would), then it will prevent that data from being executed as code.
This becomes a particularly sticky issue if your .NET assembly is going to be used over a network instead of from a local drive - there are all sorts of .NET security configurations that might prevent this from working correctly.
Another option, and not knowing the details of your project, take this with a grain of salt: add a .exe.readme file to your install that describes to any curious users or IT people why there is an executable they weren't expecting in the installation directory :)