Dotfuscator : Error after obfuscation - vb.net

I am using dotfuscator to obfuscate my vb.net application(myapp.exe). But i am getting error while running the obfuscated file.
Below is the error when i open the exe which is obfuscated.
"The settings property 'Import' was not found. ImportSetting"
My application uses .config(myapp.exe.config) file which has setting like below
<userSettings>
<myapp.My.MySettings>
<setting name="Import" serializeAs="String">
<value>True</value>
</setting>
</myapp.My.MySettings>
</userSettings>
If i don't obfuscate then application works fine. The error comes only if i obfuscate the my application.
Procedure i follow during obfuscation:
First i open create new project in dotfuscator.
In add input assembly i add myapp.exe and myapp.vshost.exe file from the bin folder of my project.
In build menu i select destination directory and click on build.
Now obfuscated file will be generated which i will use.
So please help me to solve this error.

You may have to manually exclude ImportSetting from renaming. If this doesn't solve your problem you should probably contact Dotfuscator Support

Note that running the obfuscator will rename everything to hide it's purpose. See here, http://msdn.microsoft.com/en-US/library/ms227212(v=vs.80).aspx.
My guess is that your <myapp.My.Settings> would have to be changed to the obfuscated name. I'm not sure how you would determine that however.
Edit: It looks like dotfuscator outputs a map.xml file that specifies all the stuff that was renamed. You should be able to lookup myapp and see what it got renamed to, then update the .config file.

Related

How Can We Determine Which App.Config File Is Loading in VSTO Outlook Add-In?

We have a very strange problem with our VSTO Add-In.
In our Add-In there are label controls that read label text values from an app.config file and display text from the configuration file to the user:
<!-- app.config -->
<configuration>
<configSections>
...
</configSections>
<!-- start applicationSettings -->
<applicationSettings>
<OurVSTOAddIn.MySettings>
<setting name="ackMsg" serializeAs="String">
<value>Some text here that we want to display and change</value>
</setting>
...
<OurVSTOAddIn.MySettings>
</applicationSettings>
</configuration>
'vb.net code
objCheckDialog.lblAttachmentsMsg.Text = My.Settings("attachmentsAckMsg").ToString()
objCheckDialog.lblAttachmentsMsg.Visible = True
We recently updated the app.config file to replace English display information with Kanjii for our end-users in Japan.
When we rebuilt the MSI and installed on our test machine, the add-in isn't displaying Kanjii (although it display correctly in development).
Now we're wondering if the configuration file in the installation directory is being read at all or if the information is cached or the add-in is reading from another file somewhere.
What's even more strange is that we've changed other values in our app.config file that are being used in code logic, and these seem to load properly.
We're currently using Procmon in an effort to find out how the config file is loaded, however, while filtering on the following:
Process Name contains Outlook
Path Contains "OurOutlookPlugInName"
This produces over 400 results but we don't see any file handling for our config file unless I debug the code in Visual Studio.
On our installation machine, we also removed the configuration file from the installation directory thinking this might be a clue as to whether the Add-In is reading the configuration file from the installation directory, but it had no effect, and the Add-In loaded normally displaying English instead of Kanjii again.
All of the configuration settins are at the Application Level.
Is there a way for us to tell where our Add-In is loading our configuration file from?
Have we done something incorrect in our MSI build that would prevent the updated configuration file from loading?
UPDATE:
I opened the dll file in the C:\Program Files (x86)\OurVSTOAddIn installation directory using Telerik JustDecompile to see if the configuration settings were written somewhere in the dll and I can see that under OurVSTOAddIn->My Settings there are definitely DefaultSettingValues there, as shown below:
This would make sense since these are Application Scoped Settings and this would prevent a user from changing config settings.
But I'm thinking if we use Application Scoped variables, each time we'll need to rebuild the msi for release, which doesn't make sense to me since the reason we want to use configuration settings for the project is to not need to rebuild for configuration changes.

Compiling Windows Form app created in VS2017 using VBC.exe?

I need to be able to program from Visual Studio but also from a usb key on computers without admin access.
To reach this goal I have used the following tutorials
VB.Net Programming Using Notepad And Command Prompt (Part I)
Tutorial(VB.Net) Creating Windows Form App Using Notepad+CommandPrompt
Now this works great without only one issue, it is hard to edit with visual studio. Intellisense doesn't work too good due to lacking files such as App.config and whatever is in the "My Project" subfolder.
So I decided to instead try to start from a VS2017 project and compile that using only vbc.exe and resgen.exe
Here is my attempt so far.
First I created a new project.
I chose a Windows Form project although the application I want to make will probably start in a "Sub Main" and run an "ApplicationContext" class instead of a form. I tried Console Application, however I find the console window annoying. I can hide the console window easily but it still flashes on startup. WPF looks too new and hard to use for now. A Windows Service might requite admin privileges to run and I'm not sure what an empty project really is.
So I create a Windows Form project
Next up I made the first two changes
I disabled the application framework.
It does something about the My namespace. It makes manual compiling much harder for some reasons. Also I changed the target .net framework to version 4.
This version is because I mostly find version "v4.0.30319" of the .net framework is installed so later version might not work.
Now, I save all that and try to build. An empty form window appears, this works so far from within visual studio at least.
For compiling I have a rudimentary .bat script.
I copy the freely available resgen.exe file to the "My Project" folder.
The code from compile.bat
path=%path%;c:\windows\microsoft.net\framework\v4.0.30319
cd "My Project"
resgen /compile Resources.resx,..\bin\debug\Resources.resources
cd ..
VBC /OUT:bin\Debug\app.exe /resource:"bin\debug\*.resources" /imports:System.Data,System.Deployment,System.Drawing,System.Windows.Forms,System.Xml,System.Xml.Linq,System.Data.DataSetExtensions,System.Collections,System.Collections.Generic,System.Data,System.Drawing,System.Diagnostics,System.Windows.Forms,System.Linq,System.Xml.Linq,System.Threading.Tasks /T:exe *.vb "My Project\*.vb"
pause
Some explanations,
First running this script with recompile the resource file and then compile the executable.
It will include all of the *.vb files as well as the resource file.
The following files are ignored so far
App.config
WindowsApp2.vbproj
My Project\Application.myapp
My Project\Settings.settings
Now the long list of imports is from the vbproj file.
It does not currently updates itself when you add more references in visual studio. A future version of this bat file will be made using vbscript and should extract and auto-add the imports/reference but not there yet.
Now what happens when you run this ?
It does not work with 3 errors as follows :
First it does not respect the defined startup object
This object is defined in the .vbproj file as follows
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<StartupObject>WindowsApp2.Form1</StartupObject>
</PropertyGroup>
</Project>
This section is not taken into account by vbc.exe yet so it appears to default to using a Sub Main and gives this first error.
vbc : error BC30420: 'Sub Main' was not found in 'app'.
Second and third errors as follows
C:\defaultpath\Visual Studio 2017\Projects\WindowsApp2\WindowsApp2\My
Project\Settings.Designer.vb(67) : error BC30002: Type 'WindowsApp2.My.MySetting
s' is not defined.
Friend ReadOnly Property Settings() As Global.WindowsApp2.My.MySettings
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:\defaultpath\Visual Studio 2017\Projects\WindowsApp2\WindowsApp2\My
Project\Settings.Designer.vb(69) : error BC30456: 'WindowsApp2' is not a member
of '<Default>'.
Return Global.WindowsApp2.My.MySettings.Default
Both of these errors are related somehow to the Root Namespace configuration
This is declared in the .vbproj file but not currently taken into account by the compile.bat file
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<RootNamespace>WindowsApp2</RootNamespace>
</PropertyGroup>
</Project>
In the document Visual Basic Compiler Options Listed Alphabetically
The option /rootnamespace is defined to "Specifies a namespace for all type declarations."
So I add the /rootnamespace:WindowsApp2 to my compile.bat file and both previous issues listed above are solved.
Lastly, to fix the Sub Main issue and instead use "WindowsApp2.Form1" as defined in the .vbproj file
The /main command seems to fit the bill for this, so I add /main:WindowsApp2.Form1 to the command line.
Following some last minute changes to .resource file handling here is the latest compile.bat
path=%path%;c:\windows\microsoft.net\framework\v4.0.30319
cd "My Project"
resgen Resources.resx
cd ..
VBC /OUT:bin\Debug\app.exe /main:WindowsApp2.Form1 /rootnamespace:WindowsApp2 /resource:"My Project\*.resources" /imports:System.Data,System.Deployment,System.Drawing,System.Windows.Forms,System.Xml,System.Xml.Linq,System.Data.DataSetExtensions,System.Collections,System.Collections.Generic,System.Data,System.Drawing,System.Diagnostics,System.Windows.Forms,System.Linq,System.Xml.Linq,System.Threading.Tasks /T:exe *.vb "My Project\*.vb"
pause
This compiles an executable without errors.
I run it and Form1 appears, unfortunately the Console window also appears !
So it seems I still have a Console App and not a Windows Form App
This is resolved by modifying the /T parameter defined as /target from exe to winexe
Final compile.bat
path=%path%;c:\windows\microsoft.net\framework\v4.0.30319
cd "My Project"
resgen Resources.resx
cd ..
VBC /OUT:bin\Debug\app.exe /main:WindowsApp2.Form1 /rootnamespace:WindowsApp2 /resource:"My Project\Resources.resources" /imports:System.Data,System.Deployment,System.Drawing,System.Windows.Forms,System.Xml,System.Xml.Linq,System.Data.DataSetExtensions,System.Collections,System.Collections.Generic,System.Data,System.Drawing,System.Diagnostics,System.Windows.Forms,System.Linq,System.Xml.Linq,System.Threading.Tasks /T:winexe *.vb "My Project\*.vb"
pause
If anyone has any comments or suggestions I would gladly hear them.
I started writing this as a question but I resolved my issues in the course of writing this question.
If there is an easier way to do this please let me know.
In the mean time I hope this can be useful to someone else on the same path as I.
Bye !

MSBUILD Dynamically Create Config XML Dotfuscator

I am trying to obfuscate bunch of files in a directory and every build there are more and more files being generated. I would like to know if there is a way I can dynamically create the Dotfuscator configuration xml file using a MSBUILD task that will generate the xml file every time there is a new file added to the directory?
This might be a good time to use the Directory input. Rather than representing a single assembly (.exe or .dll), this type of Dotfuscator input captures all the assemblies in a directory. When the contents of the directory change, Dotfuscator's build will automatically pick up any new assemblies.
To make a Dotfuscator config file with a Directory input, open the GUI and add an input as you normally would (directions for Community Edition's GUI and for Professional Edition's standalone GUI), but instead of selecting a file from the Browse... dialog, just navigate to the directory and click "Open" while the "File name" is still listed as "Folder Select". Then, save your configuration.
From now on, whenever you run Dotfuscator (whether from the standalone GUI, the command line, the Visual Studio integration, or the MSBuild task), all assemblies in the directory will be processed as input.
Note: If you look at the config file itself, you might be surprised that it will still list individual assemblies:
<input>
<loadpaths />
<asmlist>
<package refid="19e1b0c5-7221-476f-af4b-bafef68edc95">
<file dir="C:\code\BasicTestApp\BasicTestApp\bin" name="Debug" />
<asmlist>
<inputassembly refid="a6da5d8d-c181-4103-840d-d8cc7c85937a">
<option>honoroas</option>
<option>stripoa</option>
<option>transformxaml</option>
<file dir="" name="BasicTestApp.exe" />
</inputassembly>
<inputassembly refid="df84dad0-fbe8-49ab-b8c8-9fb59e706785">
<option>honoroas</option>
<option>stripoa</option>
<option>library</option>
<option>transformxaml</option>
<file dir="" name="ClassLibrary.dll" />
</inputassembly>
</asmlist>
</package>
</asmlist>
</input>
Despite this layout, Dotfuscator will process all assemblies in the C:\code\BasicTestApp\BasicTestApp\bin\Debug directory when it runs a build based off this config file, not just those two listed.
The assembly elements in the config are just there so that you can still make rules against individual assemblies in the GUI (e.g., to make one assembly be in Library Mode).
The list represents the state of the directory when the GUI last modified the config.
Disclaimer: I work for the Dotfuscator team, and am answering this question as part of my job.
Additional note due to clarification in the comments: the directory package has a feature where you can exclude certain assemblies from obfuscation. These assemblies will be treated as a Package Artifact and just copied from input-to-output without modification. Any obfuscated assemblies that refer to these excluded assemblies will still be processed correctly.
To do this in the GUI, right-click on the assembly within the package, and select "Exclude assembly from package". Or, if you'd prefer to edit the config file, add the following <option> tag as a child of each relevant <inputassembly> tag:
<option>artifact</option>
The latest Dotfuscator version 4.41.1 has the latest flag
true
This will generate the Dotfuscator config file if the file is missing. Also you can add this to the csproj as documented in the latest getting started guide https://www.preemptive.com/dotfuscator/pro/userguide/en/getting_started_protect.html

Getting rid of App.exe.config

I am working on a vb.net application that uses SQLite and since it was compiled against the version 2 of the .net framework, i added this line to my config file
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
</startup>
My final objective for the application is to make it a standalone, so not a single file except the exe (well the application will generate a file for the database, but my point is i want the user to only download 1 single file).
And i noticed that when i build it, the config file is always copied, and if i run the application without the config file, i would get the uncaught exception "legacy" error..
Is there any way to either include that config during runtime? or perhaps catch some type of exception to prevent that dialog from showing up and scaring the user (i know this probably not the best approach)
I have searched and found other similar problems on SO but none of the questions i found got to a solution that worked for me so i would appreciate your help.
While it is possible to set the legacy runtime policy at runtime, I would recommend deploying as an installer.
well the application will generate a file for the database, but my point is i want the user to only download 1 single file
They could download your installer, which could take care of setting up everything correctly. This is likely to be required in any case, as SQLite will need its own DLLs as well as your .exe to be there in the deployment.

Using Netbeans to configure context-root for JBoss

I have a Spring application that is being deployed to JBoss 4.2. I can manually edit the generated WAR file and alter the jboss-web.xml file to set the context-root value and that works perfectly well. I would like to be able to do the samething via netbeans (6.9.1), but I have been unable to locate where to make the adjustment. I've tried tweaking the project's properties and setting the Context Path value. When I Run the application that value is reset to the Project's name. I've located the jboss-web.xml file in the project and changed it there, also reset upon run. So it appears that Netbeans is deciding that the value need to be set but I can't locate where. If it's of any use, the project also uses Maven2, but all the controls I can find for impacting context-root are geared towards EAR files instead of WAR.
Has anyone been able to do this or am I just in a world of making the change post build?
I had a similar problem once where netbeans was sometimes removing the context-root element from the glassfish-web.xml configuration. I have not been able to track it down exactly but you could try to remove the file nb-configuration.xml in the project root folder and see if that helps.