I need to maintain an xslt code that has 10s of thousands of lines.
It was developed a long time ago and it is integrated to a visual studio console application by running xsltc as a pre build event that creates a dll and that dll is finally referenced by the visual studio project.
In order to sell the final executable, I need to obfuscate the whole solution.
The tool I have been using to obfuscate works correctly for all executables and dlls files created by visual studio, but if I obfuscate my xslt dll, then my code throws a runtime error saying that it cannot find my xslt dll.
I would like to know, if you have already worked on projects using xslt dlls, how did you manage to maintain a secure version of these dlls?
I have deleted the pre-build event that ran xsltc and used the input stylesheet as an embedded resource that is not copied to the output directory.
As the stylesheet is not copied to the output directory anymore, I changed the loading code a bit:
XsltSettings settings = new XsltSettings(true, true);
Stream stream = Assembly.GetExecutingAssembly().GetManifestResourceStream("namespace.stylesheetname.xslt");
XmlReader embeddedReader = XmlReader.Create(stream);
XslCompiledTransform xslt = new XslCompiledTransform();
xslt.Load(embeddedReader, settings, new XmlUrlResolver());
Now I have a single executable file that I could finally obfuscate.
If you intend to use the code above, double check that you are closing the files you have opened.
Related
In the older version of the visual studio, it was possible to build a small "Hello World" application that has a single .exe file and size around 200KB. I started to use a new version of Visual Studio and I have with this simple task.
When I build it with parameters:
<PublishTrimmed>true</PublishTrimmed>
<PublishReadyToRun>true</PublishReadyToRun>
<PublishSingleFile>true</PublishSingleFile>
The output is single .exe, but with the size around 25MB. When I build it as "Framework dependent", the .exe is around 150KB, but it has additional 2 .json configuration files.
Is it possible now to publish a single small .exe file without the .json configuration files in Visual Studio?
You can try to use Costura.Fody to make a single exe without another file.
The following link is a similar question, you can refer to it to solve this problem.
How to make a Single exe file from c# assembly and dll?
I use xsltc.exe in developer console (ms visual studio). I try to generate a DLL that could be used in a .NET project.
xsltc /settings:dtd /settings:document /settings:script /c:Bk24.Specs specs.xsl /out:Bk24Specs.dll
I have successfully generated many of such DLLs before, but now I have a big problem. The current XSL contains a reference to an XML
<xsl:variable name="spcodes" select="document('specialCodes.xml')/list/data" />
I successfully generated the DLL for this template. I added a reference to this DLL in the .NET project. But then, the application throws an exception
File not found (c:\projects\bk24\specialCodes.xml)
in the real production environment. Of course, on the client's workstation there is no such directory C:\projects\bk24\. It's my directory on my dev machine, but when I ran xsltc.exe, I put specialCodes.xml into the same directory where the XSL is placed. I hoped that xsltc.exe would look at the directory, found that XSLs and XMLs are in the same directory, so, the generator will embed the XMLs into this DLL, but, it seems, it's not...
How can I resolve this issue?
If it is only a read only file, then open the file in a text editor and copy it. Then embed it as a string in any cs class and read with XElement.Parse(that_string)
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
I wrote a form application in c# using Visual Studio 2008, third party dlls, an xml file and images. The images have been added to the project as resources.
A System.IO.FileNotFoundException is thrown when I attempt to run the published version of the executable on another machine.
If I copy the .exe file to the desktop on the pc, and also copy the dlls and the xml file to the desktop, double clicking on the exe works fine.
In my project, I have the copyLocal set to true for the required dll references. The xml is added to the project and set to copy if newer to output directory. I also checked the publish application files and everything is there.
The line I use to load the xml file is this
config = new XmlDocument();
config.Load("fileName.xml");
I'm assuming the FileNotFound exception is being thrown when you try to load the XML file, right?
Simply looking for "filename.xml" doesn't seem like a fantastic idea to me, especially if this is a key configuration file for your application.
I typically try to move these things into my App.config file then load them either using a fully qualified path or a short path. For example:
App.config
<add key="ExternalConfig" value="D:\\config.xml"/>
.cs file
config = new XmlDocument();
config.Load(ConfigurationManager.AppSettings["ExternalConfig"]);
You could also use a relative path, but keep in mind that you're always relative to the current working directory.
Alternatively, based on the type of data in your configuration, you could try to store this information to you App.config file and do away with a config.xml altogether.
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.