I have Disassembled a WPF (Prism).dll file (Microsoft.Practices.Prism.UnityExxtensions.dll) using ILDASM, there I got 3 files with extensions like .IL, .res and .g.resources. I have changed the version number of a referenced file in metadata of the .IL file. Now I need to again Assemble it into a .dll.
You can use ilasm tool.
I have heard about this workaround too. Make a new application. Add all the resource files then select all files and change the build action to embedded resources for all files.
Related
I'm trying to use Log4net for my c# application. But when my application runs it generates log4net.xml file. As I read , It includes some information related to use in .NET documentation . But I no need this file or documentation.
How to disable log4net.xml file generation.
Your application is NOT generating this file. This file is part of the Log4Net project alongside with the assembly (log4net.dll) and the public debugging symbols (log4net.pdb). Those file are simply copied to your application's output directory. If you don't want to have them (even though it is strongly recommended to keep them), you could remove them from the source.
If on the other hand you downloaded the source code of Log4Net and compiled it yourself, then you could disable XML documentation generation in the properties of the project. In this case no log4net.xml file will be emitted.
If you are using log4net project from NuGet, remove log4net.xml file from the packages folder that was created by the NuGet(that file is under the /lib/<.net framework version>) and it will not get copied to your output.
Open command prompt as administrator
cd C:\WINDOWS\assembly\GAC_64\log4net\1.2.10.0__692fbea5521e1304
Rename log4net.dll 64bit to log4net64.dll
Copy log4net.dll 32bit to folder
C:\WINDOWS\assembly\GAC_64\log4net\1.2.10.0__692fbea5521e1304
Maybe not possible but I have an application that gets text from a bunch of text files organised in folders which are all included in my project. However I'd love to compile these text files into the exe so that I don't have to lug the folders with the application. Anyway I can do this?
The folders are in a hierarchy i.e. each folder has a txt file and image that my application uses. At the moment they are all set to build as Embedded Resources which I thought would have compiled them in but unfortunately not.
Preferably I love if there was a way I could add the folder rather than each file individually.
"Compilation" means something else.
Anyway, .NET confusingly uses the same terms to describe "embedded resources", which are exposed as resource streams from the assembly, and the more API-friendly resx resources which are then compiled into .resources files that are also stored as embedded resource streams.
If you want to use ResX resources in your project then go Add New Item > Resources (resx), then go to the Files tab and add references to your filesystem files, then build your project. You'll be able to access those files by going typing FooResources.MyFileName in your program's code, assuming you named your resx file FooResources.
I want to create a self-extracting executable in C#.
The requirement is that when I build my C# project, the output of the build should be a self-extracting EXE file which will contain all the files and folders of a predetermined path recursively.
When I run the EXE file generated by building the project, it then extracts all the files to a predetermined folder.
How can I achieve this in C#?
You can embed any number of files of arbitrary type into a C# executable, and emit them during runtime. Here is a good tutorial. This embedding approach is usually used to pack all DLLs your executable refers to into the executable itself (see e.g. this), but it is also appropriate to make a self-extracting executable.
Better use a setup like NSIS. It is easy to use and generates a single EXE file.
I have a .NET C# 2.0 Project and it refers to many .xml files, i'd need these files when i port my project to another location or distribute it. I'm currently not interested in making it as a setup.exe file. I want to to be standalone. currently i've got all of them in a folder "FILES" within my project. So what i want to know is
Can i pack all these XML files inside a dll, so that it's secure and portable? If so how to do it?
When i build the program the FILES folder is not copied. How can i make it copy it as well?
You can mark the xml files as resources, and they will be packaged inside the assembly. Just set the "build action" to "embedded resource". Alternatively, use a resource file (resx), and drag the xml files onto the resx designer, and it'll do everything for you (including providing access methods to get the data back out).
We're using our .NET Assembly DLL within native C++ through COM (CCW).
Whenever I make new version of my DLL, I have to send two files (.dll and corresponding .tlb) to crew that's using it in their code.
Is it possible to embed .tlb file as a resource in .NET DLL file?
It is not exactly straightforward to do this with Visual Studio .NET, but it can be done. At a basic level, what you have to do is this:
Generate your TLB file, e.g., "YourLibrary.tlb".
Create a Win32 resource script file called, for example, "YourLibrary.rc" using a text editor (such as Notepad, or File/New/File.../Text File in Visual Studio).
In the script file, type the following text verbatim (but substitute your actual TLB file name of course):
1 typelib "YourLibrary.tlb"
Save the script file to the same folder as the TLB file.
From a Visual Studio Command Prompt, change to the folder with the script file and compile it using the following command:
rc YourLibrary.rc
This will generate a Win32 resource file in the same folder called "YourLibrary.res".
In Visual Studio, right click the project node (e.g., "YourLibrary") in the Solution Explorer and select Properties.
On the Application tab, under "Resources", select the "Resource File" option and browse to the "YourLibrary.res" file from step 5.
Save and rebuild the project.
The TLB will now be embedded as a resource in the DLL such that other COM applications can read it.
If you regenerate the TLB file later you will need to repeat step 5 to recompile the resource file, and step 8 to embed the new version in the DLL.
All that said, you may be able to automate some of this with Build Events or by putting custom MSBuild targets into your project file, but that is a whole other discussion.