Dotfuscator and ClickOnce
Stewart Berman
Deploying Obfuscated Assemblies
You might want to obfuscate your application by using Dotfuscator to prevent others from reverse
engineering the code. However, assembly obfuscation is not integrated into the Visual Studio IDE or
the ClickOnce deployment process. Therefore, you will have to perform the obfuscation outside of the
deployment process, perhaps using a post-build step. After you build the project, you would perform
the following steps manually, outside of Visual Studio:
Perform the obfuscation by using Dotfuscator.
Use Mage.exe or MageUI.exe to generate the ClickOnce manifests and sign them. For more information,
see Mage.exe (Manifest Generation and Editing Tool) and MageUI.exe (Manifest Generation and Editing
Tool, Graphical Client).
Manually publish (copy) the files to your deployment source location (Web server, UNC share, or
CD-ROM
It appears to be something that can be done with a simple script but I have yet to find one.
Is there a step by step example for doing the above for a simple ClickOnce Windows Forms application
with a single executable? Something like:
1. Build application
2. Run Dotfuscator -- sample command.
3. Run Marge --sample command
4. Manually publish -- [I think this is straight forward but a sample walk through would clarify
it.]
Also, assuming steps (1), (2) and (3) are done why can't the publish wizard be used?
Linda Liu[MSFT]
My suggestion is to use publish wizard provided by Visual Studio to publish
the ClickOnce application first and then use the dotfuscator to obfuscate
the executable in the publish location. The last step is to use mage to
update and resign the ClickOnce manifests.
The above work except that done by the publish wizard can be written in a
bat file. The following is a sample. It assumes the publish location is
http://localhost/TestWinForm and the current version is 1.0.0.4. Copy the
certificate file (.pfx) to the publish location. It also assumes that the
password of the certificate file is 1.
========================================
cd c:\inetpub\wwwroot\TestWinForm\TestWinForm_1_0_0_4
md .\temp
copy TestWinForm.exe.deploy .\temp
rename .\temp\TestWinForm.exe.deploy TestWinForm.exe
path of dotfuscator \ dotfuscator /in: .\temp\TestWinForm.exe
mage -u TestWinform.exe.manifest -fd .\temp -cf
.\testwinform_temporarykey.pfx -pwd 1
rename .\temp\TestWinForm.exe TestWinForm.exe.deploy
copy .\temp\TestWinForm.exe.deploy TestWinForm.exe.deploy
del .\temp /Q
rd .\temp /Q
cd ..\
mage -u TestWinForm_1_0_0_4.application -appm
\TestWinForm_1_0_0_4\TestWinForm.exe.manifest -cf
testwinform_temporarykey.pfx -pwd 1
copy TestWinForm_1_0_0_4.application TestWinForm.application
=========================================
To summarize, the first step is to use the publish wizard to publish the
application. The second step is to copy the certificate file used to sign
the ClickOnce manifest by Visual Studio to the publish location. The third
step is to run the above .bat file in the Visual Studio 2005 Command Prompt
to obfuscate the executable and update and resign the ClickOnce manfiests.
Hope this helps.
If you have any question, please feel free to let me know.
Sincerely,
Linda Liu
Microsoft Online Community Support
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msd...@microsoft.com.
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Stewart Berman
our web site. I cannot run command line applications on their server.
How do I use Dotfuscator -- shipped with Visual Studio 2005 -- on my development machine before
publishing to the web site?
I need to run Dotfuscator and Mage on my development machine after the build completes and before
publishing. Is there someway to export the equivalent of a make file for the build process? It
appears that all that is needed is to run Dotfuscator after the compile and link and before creating
and signing the exe and manifest although I would rather do it as part of the publish process than
the build process.
Where is the definition of the build process stored? It seems that the Dotfuscator, manifest
generation and signing could easily be incorporated into the publication process.
Linda Liu[MSFT]
After spending several hours on this issue, I find a better solution to
your problem.
Firstly, Visual Studio uses MSBuild to build and publish ClickOnce
applications. Please read the following MSDN documents for information on
MSBuild:
"MSBuild Overview"
http://msdn.microsoft.com/en-us/library/ms171452.aspx
"MSBuild Targets"
http://msdn.microsoft.com/en-us/library/ms171462.aspx
"MSBuild Tasks"
http://msdn.microsoft.com/en-us/library/ms171466.aspx
Secondly, every Visual Studio project imports the Microsoft.Common.targets
file, which describes the steps to build and publish an application in
common. The Microsoft.Common.targets file resides in the
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\. Open this file with Notepad
and you can see the detailed information on the tasks performed when you
build and publish an application with Visual Studio.
As you can see, there're targets called Build and PublishOnly in the
Microsoft.Common.targets file. Visual Studio uses these two targets to
build and publish projects. The Build target build the project and generate
ClickOnce manifests. So we need to do the obfuscation after the main
assembly is generated and before the ClickOnce manifests are created.
Fortunately, there's a AfterCompile target, which is built after the
Compile target (which means the main assembly has been generated), and
before the GenerateManifets target (which will generate ClickOnce
manifests). The solution is to add a task inside the "AfterCompile" target
to the project file to call the Dotfuscator command line. Open the project
file with Notepad and add the following snippet after the <Import
Project="$(MSBuildBinPath)\Microsoft.CSharp.targets"/>:
<Target Name="AfterCompile">
<Exec Command="path\Dotfuscator /in:
$(IntermediateOutputPath)appname.exe /out: $(IntermediateOutputPath) "/>
</Target>
Save the project file and reload the project in Visual Studio. Clear and
publish the project within Visual Studio. You should see the generated
executable is obfuscated and then published successfully.
In addition, you can execute the MSBuild command in Visual Studio 2005
Command Prompt to build and publish the project. It's equivalent to
building and publishing within VS and what's important is that you can see
detailed information when MSBuild builds and publishs the project which is
always useful. The command line looks like:
msbuild path\projectname.csproj /t:build, publishonly
Please try my suggetion to see if there's any problem.
Stewart Berman
> <Exec Command="path\Dotfuscator /in:
>$(IntermediateOutputPath)appname.exe /out: $(IntermediateOutputPath) "/>
></Target>
This does not work with the Dotfuscator Community Edition shipped with Visual Studio 2005.
v-l...@online.microsoft.com (Linda Liu[MSFT]) wrote:
Stewart Berman
<Target Name="AfterCompile" Condition="'$(Configuration)'=='Release'">
<Exec Command=""$(DotfuscatorBinPath)" /q
"-in:$(ProjectDir)$(IntermediateOutputPath)$(TargetFileName)"
"-out:$(ProjectDir)$(IntermediateOutputPath)."
"-mapout:$(ProjectDir)$(IntermediateOutputPath)$(AssemblyName).Map.xml" -clobbermap:on "
/>
</Target>
sort of working. That is it starts Dotfuscator during the build and all I have to do is press its
build button and then close it.
Unfortunately, if you open the project's properties and do anything Dotfuscator gets kicked off
multiple times. It also gets kicked of a few times after you hit the publish button. So putting
into the build process is not a solution.
How about this:
1. Run a normal build
2. Manually run Dotfuscator put the results back into the bin\release directory
Now what Mage commands need to be run before publishing:
<Target Name='BeforePublish'>
<-- What goes here? -->
</Target>
v-l...@online.microsoft.com (Linda Liu[MSFT]) wrote:
Stewart Berman
Name='AfterCompile' does nothing. Actually, it does dotfuscator the executable in obj\Release and
bin\Release. Unfortunately, when Publish recompiles the application all of the original code is
back in it.
v-l...@online.microsoft.com (Linda Liu[MSFT]) wrote:
Stewart Berman
Dotfuscator is commented out because it doesn't work from the command line. If I just hit enter at
the PAUSE the results is still installable from the publish.htm page. However, if I run Dotfuscator
from Visual Studio 2005 and target the ApplicationName.exe in the Temp directory and then hit enter
to run the rest of the script the results will not install. The error message is:
Strong name signature not valid for this assembly ApplicationName.exe
Doesn't the ApplicationName.exe have to be signed again after applying Dotfuscator?
Script:
W:
CD "\Inetpub\website\ApplicationName\ApplicationName_1_0_0_105"
IF NOT EXIST Temp GOTO :SKIPRD
DEL Temp\*.* /Q /S
RM Temp /Q /S
:SKIPRD
MD Temp
COPY ApplicationName.exe.deploy .\Temp\ApplicationName.exe
COPY MONITR01.ICO.deploy .\Temp\MONITR01.ICO
COPY ApplicationName.exe.config.deploy .\Temp\ApplicationName.exe.config
REM "C:\Program Files\PreEmptive Solutions\Dotfuscator Enhanced Community Edition
4.2\dotfuscator.exe"
"/in:W:\Inetpub\website\ApplicationName\ApplicationName_1_0_0_105\Temp\ApplicationName.exe"
"/out:W:\Inetpub\website\ApplicationName\ApplicationName_1_0_0_105\Temp" "-mapout:H:\Visual Studio
2005\Projects\ApplicationName\ApplicationName.Map.xml" -clobbermap:on /q
PAUSE
"C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\Mage.exe" -u ApplicationName.exe.manifest
-fd .\Temp -cf "H:\Visual Studio
2005\Projects\ApplicationName\ApplicationName\ApplicationName_TemporaryKey.pfx" -pwd ***
COPY .\Temp\ApplicationName.exe ApplicationName.exe.deploy /Y
COPY .\Temp\MONITR01.ICO MONITR01.ICO.Deploy /Y
COPY .\Temp\ApplicationName.exe.config ApplicationName.exe.config.deploy /Y
DEL Temp /Q
RD Temp /Q
CD ..
"C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\Mage.exe" -u
ApplicationName_1_0_0_105.application -appm ApplicationName_1_0_0_105\ApplicationName.exe.manifest
-cf "H:\Visual Studio
2005\Projects\ApplicationName\ApplicationName\ApplicationName_TemporaryKey.pfx" -pwd ***
COPY ApplicationName_1_0_0_105.application ApplicationName.application /Y
The output of the script executing:
C:\>W:
W:\>CD "\Inetpub\WebSite\ApplicationName\ApplicationName_1_0_0_105"
W:\Inetpub\WebSite\ApplicationName\ApplicationName_1_0_0_105>IF NOT EXIST Temp GOTO :SKIPRD
W:\Inetpub\WebSite\ApplicationName\ApplicationName_1_0_0_105>MD Temp
W:\Inetpub\WebSite\ApplicationName\ApplicationName_1_0_0_105>COPY ApplicationName.exe.deploy
.\Temp\ApplicationName.exe
1 file(s) copied.
W:\Inetpub\WebSite\ApplicationName\ApplicationName_1_0_0_105>COPY MONITR01.ICO.deploy
.\Temp\MONITR01.ICO
1 file(s) copied.
W:\Inetpub\WebSite\ApplicationName\ApplicationName_1_0_0_105>COPY ApplicationName.exe.config.deploy
.\Temp\ApplicationName.exe.config
1 file(s) copied.
W:\Inetpub\WebSite\ApplicationName\ApplicationName_1_0_0_105>REM "C:\Program Files\PreEmptive
Solutions\Dotfuscator Enhanced Community Edition 4.2\dotfuscator.exe"
"/in:W:\Inetpub\WebSite\ApplicationName\ApplicationName_1_0_0_105\Temp\ApplicationName.exe"
"/out:W:\Inetpub\WebSite\ApplicationName\ApplicationName_1_0_0_105\Temp" "-mapout:H:\VisualStudio
2005\Projects\ApplicationName\ApplicationName.Map.xml" -clobbermap:on /q
W:\Inetpub\WebSite\ApplicationName\ApplicationName_1_0_0_105>PAUSE
Press any key to continue . . .
W:\Inetpub\WebSite\ApplicationName\ApplicationName_1_0_0_105>"C:\Program Files\Microsoft Visual
Studio 8\SDK\v2.0\Bin\Mage.exe" -u ApplicationName.exe.manifest -fd .\Temp -cf "H:\Visual Studio
2005\Projects\ApplicationName\ApplicationName\ApplicationName_TemporaryKey.pfx" -pwd ***
ApplicationName.exe.manifest successfully signed
W:\Inetpub\WebSite\ApplicationName\ApplicationName_1_0_0_105>COPY .\Temp\ApplicationName.exe
ApplicationName.exe.deploy /Y
1 file(s) copied.
W:\Inetpub\WebSite\ApplicationName\ApplicationName_1_0_0_105>COPY .\Temp\MONITR01.ICO
MONITR01.ICO.Deploy /Y
1 file(s) copied.
W:\Inetpub\WebSite\ApplicationName\ApplicationName_1_0_0_105>COPY .\Temp\ApplicationName.exe.config
ApplicationName.exe.config.deploy /Y
1 file(s) copied.
W:\Inetpub\WebSite\ApplicationName\ApplicationName_1_0_0_105>DEL Temp /Q
W:\Inetpub\WebSite\ApplicationName\ApplicationName_1_0_0_105>RD Temp /Q
W:\Inetpub\WebSite\ApplicationName\ApplicationName_1_0_0_105>CD ..
W:\Inetpub\WebSite\ApplicationName>"C:\Program Files\Microsoft Visual Studio
8\SDK\v2.0\Bin\Mage.exe" -u ApplicationName_1_0_0_105.application -appm
ApplicationName_1_0_0_105\ApplicationName.exe.manifest -cf "H:\Visual Studio
2005\Projects\ApplicationName\ApplicationName\ApplicationName_TemporaryKey.pfx" -pwd ***
ApplicationName_1_0_0_105.application successfully signed
W:\Inetpub\WebSite\ApplicationName>COPY ApplicationName_1_0_0_105.application
ApplicationName.application /Y
1 file(s) copied.
v-l...@online.microsoft.com (Linda Liu[MSFT]) wrote:
Linda Liu[MSFT]
Thank you for your replies!
> Unfortunately, if you open the project's properties and do anything
Dotfuscator gets kicked off multiple times.
Yes, it is. If you don't like it, you'll have to adopt the first solution I
suggested in my first reply.
> Publish recompiles the application.
Yes, it is.
> Unfortunately, when Publish recompiles the application all of the
original code is
back in it.
When Publish recompiles the application, the AfterCompile target will also
be built. So if we obfuscate the executable in the AfterCompile target, the
application will be always obfuscated when it is published. If you run the
MSBuild.exe command in the VS2005 Command Prompt to publish the
application, you'll see the detailed information on the execution of the
tasks.
> Doesn't the ApplicationName.exe have to be signed again after applying
Dotfuscator?
After applying Dotfuscator, only the application manifest and deployment
manifest must be updated and resigned.
> The error message is:
Strong name signature not valid for this assembly ApplicationName.exe
It looks like you strong-name the assembly. I have tried to strong-name an
executable and apply dotfuscator on it. The result is that the executable
can't run at all. This is just the purpose of strong name signing, i.e. a
strong named assembly could not be changed once it is generated. Any way,
it's not recommended to strong-name application EXE assemblies.
Kuemerle@discussions.microsoft.com Joe Kuemerle
> > Doesn't the ApplicationName.exe have to be signed again after applying
> Dotfuscator?
>
> After applying Dotfuscator, only the application manifest and deployment
> manifest must be updated and resigned.
>
> > The error message is:
> Strong name signature not valid for this assembly ApplicationName.exe
>
> It looks like you strong-name the assembly. I have tried to strong-name an
> executable and apply dotfuscator on it. The result is that the executable
> can't run at all.
This occurs because obfuscation changes the binary by renaming all of the
symbols within in and thus the assembly no longer hashes to the original
value of the strong name signature. Whenever a strong named assembly is
obfuscated it must be resigned after the obfuscation has taken place in order
that a new strong name signature is generated. This also applies to
Authenticode signing of assemblies that you wish to obfuscate.
Stewart Berman
Unfortunately, I hit another problem with the Dotfuscator code:
Thread: 1 | 20090727 14:33:59.484: Unable to access application's settings
System.Configuration.SettingsPropertyNotFoundException: The settings property 'IsInitialized' was
not found.
at System.Configuration.SettingsBase.GetPropertyValueByName(String propertyName)
at System.Configuration.SettingsBase.get_Item(String propertyName)
at System.Configuration.ApplicationSettingsBase.GetPropertyValue(String propertyName)
at System.Configuration.ApplicationSettingsBase.get_Item(String propertyName)
at k.m()
at e.h()
Thread: 1 | 20090727 14:34:14.796: Unable to save settings:
System.Configuration.SettingsPropertyNotFoundException: The settings property 'DefaultDuration' was
not found.
at System.Configuration.SettingsBase.SetPropertyValueByName(String propertyName, Object
propertyValue)
at System.Configuration.SettingsBase.set_Item(String propertyName, Object value)
at System.Configuration.ApplicationSettingsBase.set_Item(String propertyName, Object value)
at k.b(Int32 A_0)
at e.d()
It appears Dotfuscator strips something out of the executable that is needed to get settings. The
error thrown when trying to set the value of a setting is because the name/value pair was not added
to the collection of settings due to the first error.
v-l...@online.microsoft.com (Linda Liu[MSFT]) wrote:
Stewart Berman
but as part of the script I was using to run Dotfuscator. So the steps are:'
1. Publish from Visual Studio
2. Apply Dotfuscator
3. Apply strong name to executable
4. Update the .application and .manifest files via Mage.exe.
5. Install
Unfortunately, Dofuscator makes the application unable to access Settings. It appears that the
entire exercise of trying to use Dofuscator for ClickOnce was futile as the results does work
anyway.
Stewart Berman
>be built. So if we obfuscate the executable in the AfterCompile target, the
>application will be always obfuscated when it is published. If you run the
I added this to the project file:
<Target Name="AfterCompile" Condition="'$(Configuration)'=='Release'">
<Exec Command='CMD /C "H:\Visual Studio 2005\Projects\AfterCompileLog.cmd"'></Exec>
</Target>
Where AfterComileLog.cmd contained:
ECHO AfterCompile >> "H:\Visual Studio 2005\Projects\AfterCompile.log
DATE /T >> "H:\Visual Studio 2005\Projects\AfterCompile.log
TIME /T >> "H:\Visual Studio 2005\Projects\AfterCompile.log
I then did a Clean, Build and Publish.
Build activated AfterCompile once.
Publish activated AfterCompile five times. Clearly one would not want to run Dotfuscator five
times. Is there someway to determine which of the five calls is the one that should be used -- some
switch that can be tested?
>MSBuild.exe command in the VS2005 Command Prompt to publish the
>application, you'll see the detailed information on the execution of the
>tasks.
If I run:
msbuild /t:publish ApplicationName.vbproj /p:Configuration=Release
The AfterCompileLog.cmd is only called once. Why is it called five times when I hit Publish Now in
Visual Studio 2005?
v-l...@online.microsoft.com (Linda Liu[MSFT]) wrote:
Stewart Berman
Target CoreResGen
Target CoreCompile
Target AfterCompile
Target _CopyAppConfigFile
Target _CopyManifestFiles
Target CopyFilesToOutputDirectory
Target _CopyFilesToPublishFolder
It appears that the .application and .manifest files are created and signed in the CoreCompile task.
If you run Dotfuscatore in the AfterCompile task wouldn't you also need to update and sign the
.application and .manifest files?
v-l...@online.microsoft.com (Linda Liu[MSFT]) wrote:
Stewart Berman
>executable and apply dotfuscator on it. The result is that the executable
>can't run at all. This is just the purpose of strong name signing, i.e. a
>strong named assembly could not be changed once it is generated. Any way,
>it's not recommended to strong-name application EXE assemblies.
It turns out strong-naming the application exe is required if:
isFile = IsolatedStorageFile.GetStore(IsolatedStorageScope.Roaming Or IsolatedStorageScope.User Or
IsolatedStorageScope.Assembly Or IsolatedStorageScope.Domain, Nothing, Nothing)
is to return the same Isolated Storage path after building and publishing as long as the Assembly
version stays the same.
That allows:
isFileStream = New IsolatedStorageFileStream("ApplicationName.xml", FileMode.Open,
FileAccess.ReadWrite, isFile)
to get you the same file after installing a new version of the application.
If strong name is not used, each version of the application references a different Isolated Storage
path even if the assembly version doesn't change.
v-l...@online.microsoft.com (Linda Liu[MSFT]) wrote:
Linda Liu[MSFT]
Hi Stewart,
Thank you for your prompt response!
As for the strong-named executable assembly, you need to resign it after
applying dotfuscator. Use the Sn.exe command to resign an assembly.
> It appears that the .application and .manifest files are created and
signed in the CoreCompile task.
No. The .applicatition file is created in the GenerateDeploymentManifest
target and the .manifest file is created in the GenerateApplicationManifest
target. Both the manifest files are signed in the
_DeploymentSignClickOnceDeployment target.
> Publish activated AfterCompile five times. Clearly one would not want to
run Dotfuscator five
times. Is there someway to determine which of the five calls is the one
that should be used -- some switch that can be tested?
I found a better solution is to use the BeforePublish target to apply
dotfuscate on the executable assembly. The BeforePublish target is built
only once when publishing via Publish Wizard. For example:
<Target Name="AfterCompile">
<Exec Command="path\Dotfuscator /in:
$(IntermediateOutputPath)appname.exe /out: $(IntermediateOutputPath) "/>
</Target>
As for accessing application settings from an obsfuscated application, I
can reproduce the problem on my side. A workaround is to use the
ConfigurationManager and Configuration classes to access the application
settings by yourself rather than use the strong-typed setting class
generated by Visual Studio. The following are the methods to read and write
application settings.
string ReadSetting(string sectionGroupName, string sectionName, string
settingName)
{
Configuration configuration =
ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
// Get sectionGroup
ConfigurationSectionGroup sectionGroup =
configuration.GetSectionGroup(sectionGroupName);
// Get section
ClientSettingsSection section =
(ClientSettingsSection)sectionGroup.Sections.Get(sectionName);
// Get setting
SettingElement setting = section.Settings.Get(settingName);
// Read setting value
return setting.Value.ValueXml.InnerText;
}
void WriteSetting(string sectionGroupName, string sectionName,
string settingName,string newvalue)
{
Configuration configuration =
ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
// Get sectionGroup
ConfigurationSectionGroup sectionGroup =
configuration.GetSectionGroup(sectionGroupName);
// Get section
ClientSettingsSection section =
(ClientSettingsSection)sectionGroup.Sections.Get(sectionName);
// write setting
SettingElement setting = section.Settings.Get(settingName);
// Read setting value
setting.Value.ValueXml.InnerText = newvalue;
section.SectionInformation.ForceSave = true;
configuration.Save();
}
The above methods applies to application-scoped settings. For user-scoped
settings, since they are stored in the user.config file in the isolated
storage of the current user, it's a little complex to read and write them.
I'm performing research on this and would get back to you ASAP.
Kuemerle@discussions.microsoft.com Joe Kuemerle
> I removed the strong-name and I was able to Dotfuscator the application and still install it.
>
> Unfortunately, I hit another problem with the Dotfuscator code:
>
> Thread: 1 | 20090727 14:33:59.484: Unable to access application's settings
> System.Configuration.SettingsPropertyNotFoundException: The settings property 'IsInitialized' was
> not found.
> at System.Configuration.SettingsBase.GetPropertyValueByName(String propertyName)
<Snip stack trace>
> It appears Dotfuscator strips something out of the executable that is needed to get settings. The
> error thrown when trying to set the value of a setting is because the name/value pair was not added
> to the collection of settings due to the first error.
Dotfuscator is not removing anything but by default it is renaming
everything possible in your assembly. This includes any code that uses
reflection to dynamically invoke methods or has properties that need to map
to string literals (such as the application settings code that is auto
generated by Visual Studio)
See the Dotfuscator Knowledge Base articles for a resolution:
http://www.preemptive.com/prb-dotfuscated-application-throws-a-settingspropertynotfoundexception.html
or
http://www.preemptive.com/prb-dotfuscated-application-throws-a-settingspropertynotfoundexception-2.html
Stewart Berman
>dotfuscate on the executable assembly. The BeforePublish target is built
>only once when publishing via Publish Wizard. For example:
I would really like to get this working as publishing locally, editing the script to match the
version number, running it manually and then FTP'ing is not the way to do this long term.
I put:
<Target Name="BeforePublish" Condition="'$(Configuration)'=='Release'">
<SAB_MsgBox Prompt="BeforePublish" />
<Exec Command=""C:\Program Files\PreEmptive Solutions\Dotfuscator Enhanced Community
Edition 4.2\dotfuscator.exe" /q "$(ProjectDir)Dotfuscator_Project_Exclude.xml" " />
<SAB_MsgBox Prompt="BeforePublish" />
</Target>
into the project file. (SAB_MsgBox is a custom task I put together so I could pause the process and
check what files were created.)
The Publish Now process runs without errors. Unfortunately, the program won't install. The error
log is below. I find it interesting that the fatal error is:
+ File, ApplicationName.exe, has a different computed hash than specified in manifest.
When the warnings are:
* The file named ApplicationName.exe does not have a hash specified in the manifest. Hash
validation will be ignored.
* The file named ApplicationName.exe does not have a hash specified in the manifest. Hash
validation will be ignored.
The manifest file and the application manifest have time stamps later than the Dotfuscatored
executable. Please note that for the purpose of this test I turned off strong name signing.
I check the manifest file and it does not have a hash specified for ApplicationName.exe. However,
neither does one that was created without running Dotfuscator.
Any idea as to what could be going on?
ERROR SUMMARY
Below is a summary of the errors, details of these errors are listed later in the log.
* Activation of http://WEbSite/ApplicationName/ApplicationName.application resulted in
exception. Following failure messages were detected:
+ File, ApplicationName.exe, has a different computed hash than specified in
manifest.
COMPONENT STORE TRANSACTION FAILURE SUMMARY
No transaction error was detected.
WARNINGS
* The file named ApplicationName.exe does not have a hash specified in the manifest. Hash
validation will be ignored.
* The file named ApplicationName.exe does not have a hash specified in the manifest. Hash
validation will be ignored.
OPERATION PROGRESS STATUS
* [7/28/2009 11:09:01 PM] : Activation of
http://WEbSite/ApplicationName/ApplicationName.application has started.
* [7/28/2009 11:09:01 PM] : Processing of deployment manifest has successfully completed.
* [7/28/2009 11:09:01 PM] : Installation of the application has started.
* [7/28/2009 11:09:01 PM] : Processing of application manifest has successfully completed.
* [7/28/2009 11:09:02 PM] : Request of trust and detection of platform is complete.
ERROR DETAILS
Following errors were detected during this operation.
* [7/28/2009 11:09:02 PM] System.Deployment.Application.InvalidDeploymentException
(HashValidation)
- File, ApplicationName.exe, has a different computed hash than specified in
manifest.
- Source: System.Deployment
- Stack trace:
at System.Deployment.Application.ComponentVerifier.VerifyFileHash(String
filePath, Hash hash)
at System.Deployment.Application.ComponentVerifier.VerifyFileHash(String
filePath, HashCollection hashCollection)
at System.Deployment.Application.ComponentVerifier.FileComponent.Verify()
at System.Deployment.Application.ComponentVerifier.VerifyComponents()
at
System.Deployment.Application.DownloadManager.DownloadDependencies(SubscriptionState subState,
AssemblyManifest deployManifest, AssemblyManifest appManifest, Uri sourceUriBase, String
targetDirectory, String group, IDownloadNotification notification, DownloadOptions options)
at
System.Deployment.Application.ApplicationActivator.DownloadApplication(SubscriptionState subState,
ActivationDescription actDesc, Int64 transactionId, TempDirectory& downloadTemp)
at
System.Deployment.Application.ApplicationActivator.InstallApplication(SubscriptionState& subState,
ActivationDescription actDesc)
at
System.Deployment.Application.ApplicationActivator.PerformDeploymentActivation(Uri activationUri,
Boolean isShortcut, String textualSubId, String deploymentProviderUrlFromExtension, BrowserSettings
browserSettings, String& errorPageUrl)
at
System.Deployment.Application.ApplicationActivator.ActivateDeploymentWorker(Object state)
COMPONENT STORE TRANSACTION DETAILS
No transaction information is available.
v-l...@online.microsoft.com (Linda Liu[MSFT]) wrote:
Stewart Berman
Joe Kuemerle <Joe Kuem...@discussions.microsoft.com> wrote:
Stewart Berman
command:
C:\Program Files\Microsoft Visual Studio 8\VC>MSBuild "H:\Visual Studio
2005\Projects\ApplicationName\ApplicationName\ApplicationName.vbproj" /t:build,publish
/p:Configuration=Release /v:diagnostic 1>"H:\Visual Studio
2005\Projects\ApplicationName\MSBuild.log"
The MSBuild output included:
Done building target "BeforePublish" in project "ApplicationName.vbproj".
Target "GenerateManifests" skipped. Previously built successfully.
It does not regenerate the manifest files after the BeforePublish target. Is there a way to force
the manifest files to be generated or updated in the BeforePublish target?
Linda Liu[MSFT]
Thank you for your prompt reply!
> It does not regenerate the manifest files after the BeforePublish target.
You're right.
In the Microsoft.Common.targets file, you can see that the
GenerateManifests target is sequenced after the BeforePublish target in the
DependsOn list of the PublishOnly target. It looks as if the ClickOnce
manifests would be re-generated after the BeforePublish target is built.
But the fact is that the GenerateManifests will be skipped if the ClickOnce
manifests have been created and the number of the input files is not
changed.
After doing some research, I find that only when the Project Designer is
opened and the Publish tab is selected, the AfterCompile target will be
built for multiple times when you publish the application via Publish
Wizard. Please switch to other tabs than the Publish tab within the Project
Designer or close the Project Designer directly and right click the project
in Solution Explorer and choose Publish command to publish the application.
Alternatively, you can publish the application using MSBuild command in
VS05 Command Prompt.
To summary, use AfterCompile target to apply dotfuscate to the executable
assembly and re-sign this assembly if it is strong-named. Then publish the
application using Publish Wizard or msbuild command in the VS05 Command
Prompt. When using Publish Wizard, remember not to select the Publish tab
in the Project Designer when publishing.
Hope this helps.
If you have any question, please feel free to let me know.
Sincerely,
Stewart Berman
>GenerateManifests target is sequenced after the BeforePublish target in the
>DependsOn list of the PublishOnly target. It looks as if the ClickOnce
>manifests would be re-generated after the BeforePublish target is built.
>But the fact is that the GenerateManifests will be skipped if the ClickOnce
>manifests have been created and the number of the input files is not
>changed.
>
What is the correct way to add the GenerateManifests to the AfterPublish target? I tried a couple
of ways and while it appears to run and the manifest files are changed the results doesn't work.
>Alternatively, you can publish the application using MSBuild command in
>VS05 Command Prompt.
I got the MSBUILD version to sort of work. It builds correctly and creates the
ApplicationName/ApplicationName_X_X_X_X directory but it does not copy the contents to the web
publish site. Is there a way to get it to actually publish?
How do you change the Revision level that will be used my MSBUILD. It is not in the project file --
where is it?
Is there a conditional switch I can test to see if the process is being run under the IDE or outside
it and if so what is it?
v-l...@online.microsoft.com (Linda Liu[MSFT]) wrote:
Stewart Berman
>manifests have been created and the number of the input files is not
>changed.
One of the input files is the Application executable which was changed by Dotfuscatore (which is the
reason its hash doesn't match). There appears to be a bug in the way MSBuild checks for
dependencies.
I can put a pause in the BeforePublish target -- what file do I have to change or delete to get
GenerateManifests to run instead of being skipped?
v-l...@online.microsoft.com (Linda Liu[MSFT]) wrote:
Stewart Berman
have been away from this environment for a number of years. I find it very confusing compared to
other IDEs -- including earlier Microsoft versions.
1. It is impossible to create the same build process in and outside the IDE. That is, the same
project file (the equivalent of the old make files) is handled completely differently in the IDE
than outside via MSBuild. Some targets are executed multiple times in the IDE while others that
should be executed are not while outside the IDE no one seems to be able to predicate what targets
will be executed when.
2. There isn't any support for building and publishing ClickOnce applications outside of the IDE. It
does not appear to be possible, much less supported, to use MSBuild outside of the IDE to build and
publish a ClickOnce application.
3. The treating of the folder naming conventions on the user's C: drive for ClickOnce applications
and Isolated Storage as a Microsoft trade secret makes it difficult, if not impossible, to properly
design ClickOnce applications' use of Isolated Storage and to verify the correct installation of
ClickOnce applications.
4. It appears that Microsoft does not have definitive documentation as to what actually goes on in
an IDE Build and Publish process.
5. The documentation available on MSDN fails to connect MSBuild to the IDE. All references to VS
project files lead to MSBuild as run from a command line. But the IDE does not simply invoke
MSBuild against a project file. Which leads us back to (1) above.
Again, I admit that I have been away from this for a number of years and may be missing the obvious.
Can you recommend a book or document that would help me walk through my project file and the various
Microsoft target files and understand the process flow within MSBuild and why it is different when
invoked from the IDE than from a command line?
Linda Liu[MSFT]
> What is the correct way to add the GenerateManifests to the AfterPublish
target?
You can use the CallTarget task to call the GenerateManifests target from
within the AfterPublish target so that the GenerateManifests target will be
built after the AfterPublish target is built. For example:
<Target Name="AfterPublish">
<CallTarget Targets="GenerateManifests">
</Target>
> Is there a way to get it to actually publish?
MSBuild command doesn't do this work(VS IDE copies the ClickOnce
application as well as the manifests to the publish location by itself). So
you need to copy the relevant files to the publish location by yourself if
you don't publish the application inside VS IDE.
> How do you change the Revision level that will be used my MSBUILD. It is
not in the project file --where is it?
MSBuild uses the ApplicationVersion and ApplicationRevision properties to
determine the publish version. I only find the ApplicationVersion property
in the project file.
> Is there a conditional switch I can test to see if the process is being
run under the IDE or outside it and if so what is it?
You can use the BuildingInsideVisualStudio property to determine whether
the building process is being run inside the IDE or outside it. When inside
the IDE, this BuildingInsideVisualStudio property has a 'true' value.
> I can put a pause in the BeforePublish target -- what file do I have to
change or delete to get GenerateManifests to run instead of being skipped?
IMO, you need to change the number of the files included in the publishing
process. You can create a dummy file, e.g. a .txt file. Include this dummy
file in the ClickOnce application's application files when publishing the
application and then exclude this file during the pause, so the
GenerateManifests target won't be skipped after the BeforePubish target is
built.
But it still has a problem: the GenerateManifests task creates manifests in
the intermediate output path (obj\debug or obj\release), so you need to
copy the newly generated ClickOnce manifests from the intermediate output
path to the publish folder.
I strongly recommend you to use the AfterCompile target rather than the
BeforePublish target to apply dotfuscator to the executable assembly.
My answers to your 5 questions:
1. I agree with you. IDE doesn't only rely on the MSBuild to build and
publish applications. It does do some extra work besides the MSBuild
command.
2. You can use the MSBuild command to do the most work of building and
publishing outside of the IDE. MSBuild is capable of this. The only thing
left for publishing is to copy the relevant files to the publish location
by yourself.
3. The ClickOnce Isolated Storage on the client machines is transparent to
the developer. You needn't worry about the structure of this storage. You
can also store data into an Isolated Storage from within your ClickOnce
application without any problem.
4. I will consult this question in our internal discussion group.
5. IDE doesn't only rely on the MSBuild.
The MSDN documents on MSBuild should explain the content of the project
file and the common targets file:
"MSBuild Overview"
http://msdn.microsoft.com/en-us/library/ms171452.aspx
"MSBuild Targets"
http://msdn.microsoft.com/en-us/library/ms171462.aspx
"MSBuild Tasks"
http://msdn.microsoft.com/en-us/library/ms171466.aspx
Sincerely,
Stewart Berman
>IMO, you need to change the number of the files included in the publishing
>process. You can create a dummy file, e.g. a .txt file. Include this dummy
>file in the ClickOnce application's application files when publishing the
>application and then exclude this file during the pause, so the
>GenerateManifests target won't be skipped after the BeforePubish target is
>built.
>
If I am running Publish Now in the IDE how do I then exclude a file while paused in the
BeforePublish target?
>But it still has a problem: the GenerateManifests task creates manifests in
>the intermediate output path (obj\debug or obj\release), so you need to
>copy the newly generated ClickOnce manifests from the intermediate output
>path to the publish folder.
>
If I do this while running in the IDE won't the publication process copy them to the web site?
>3. The ClickOnce Isolated Storage on the client machines is transparent to
>the developer. You needn't worry about the structure of this storage. You
>can also store data into an Isolated Storage from within your ClickOnce
>application without any problem.
It is not transparent. For example, the structure of the Isolated Storage directory tree determines
if the next version of the application can see a file produced by the prior version. This is true
even if the Assembly Version (Application\Assembly Information\Assembly Version) is unchanged.
If the structure contains:
...
StrongName_xxxxxx
StrongName.yyyyyy
The multiple versions of the application will be able to access the same file.
If the structure contains:
...
StrongName_xxxxxx
zzzzzzz
Multiple versions of the application will not be able to access the same file.
So if a user is having problems with their Isolated Storage data disappearing when you push out a
new version of the application the structure of Isolated Storage will help you do problem
determination.
BTW, does this thread need to move to the VB.NET forums?
v-l...@online.microsoft.com (Linda Liu[MSFT]) wrote:
Stewart Berman
copy them to the correct locations so they are published to the web site.
However, I seem to get inconsistent results. That is I can publish the application and then run the
new version and it works fine. If I just publish it again it the new version doesn't work -- it
just ends after displaying the splash screen.
I think it is time to diagram the process and make sure all of it is determinant.
v-l...@online.microsoft.com (Linda Liu[MSFT]) wrote:
>Hi Stewart,
>
Linda Liu[MSFT]
Thank you for your reply!
> So if a user is having problems with their Isolated Storage data
disappearing when you push out a new version of the application the
structure of Isolated Storage will help you do problem determination.
At this point, I agree with you. But it is not recommended to operate files
installed into the ClickOnce Isolated Storage manually.
BTW, the data files of the previous version of application installed to the
data directory will be copied to the data directory of the newer version of
the same application automatically, no matter whether the data files are
generated by the ClickOnce application at run time or not. Thus the new
version of application can access the data files.
For more information on accessing local and remote data in ClickOnce
applications, please read the following MSDN document:
"Accessing Local and Remote Data in ClickOnce Applications"
http://msdn.microsoft.com/en-us/library/d8saf4wy(VS.80).aspx
> BTW, does this thread need to move to the VB.NET forums?
No. But the microsoft.public.dotnet.languages.vb newsgroup has been
migrated to VB.NET forum. Refer to the following document for more
information:
http://msdn.microsoft.com/en-us/subscriptions/aa974230.aspx
> I think it is time to diagram the process and make sure all of it is
determinant.
I still recommend you to use the AfterCompile target rather than the
BeforePublish target.
My answer to your previous question:
>4 . It appears that Microsoft does not have definitive documentation as to
what actually goes on in an IDE Build and Publish process
Yes. Only documents related to MSBuild are provided. Our product team has
confirmed that VS IDE relies mostly on MSBuild to build and publish an
application.
Stewart Berman
>data directory will be copied to the data directory of the newer version of
>the same application automatically, no matter whether the data files are
>generated by the ClickOnce application at run time or not. Thus the new
>version of application can access the data files.
Unfortunately, Data files go under Local Settings not Application Data and thus will not be flushed
back to a roaming profile. They should therefore only be used for either static data or machine
specific data.
>No. But the microsoft.public.dotnet.languages.vb newsgroup has been
>migrated to VB.NET forum. Refer to the following document for more
>information:
>http://msdn.microsoft.com/en-us/subscriptions/aa974230.aspx
>
>I still recommend you to use the AfterCompile target rather than the
>BeforePublish target.
AfterCompile is called too many times.
I have it working in BeforePublish:
<Target Name="BeforePublish" Condition="'$(Configuration)'=='Release'">
<!-- -->
<Exec Command=""H:\Visual Studio
2005\Projects\ApplicationName\ApplicationName\ListAll" "BeforePublish01Begins"" />
<SAB_MsgBox Prompt="BeforePublish Begins" />
<!-- -->
<Exec Command=""C:\Program Files\PreEmptive Solutions\Dotfuscator Enhanced Community
Edition 4.2\dotfuscator.exe" /q "$(ProjectDir)Dotfuscator_Project_Exclude.xml" " />
<Exec Command=""H:\Visual Studio
2005\Projects\ApplicationName\ApplicationName\ListAll"
"BeforePublish02AfterDotfuscator"" />
<SAB_MsgBox Prompt="BeforePublish After Dotfuscator" />
<!-- -->
<Exec Command=""C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\sn.exe" -Rca
"$(ProjectDir)$(IntermediateOutputPath)$(TargetFileName)"
VS_KEY_*****************************" />
<Exec Command=""H:\Visual Studio
2005\Projects\ApplicationName\ApplicationName\ListAll" "BeforePublish03Aftersn"" />
<SAB_MsgBox Prompt="BeforePublish After sn" />
<!-- -->
<Touch Files="$(ProjectDir)$(IntermediateOutputPath)$(TargetFileName)" />
<Exec Command=""H:\Visual Studio
2005\Projects\ApplicationName\ApplicationName\ListAll" "BeforePublish04AfterTouch""
/>
<SAB_MsgBox Prompt="BeforePublish After Touch" />
<!-- -->
<Copy SourceFiles="$(ProjectDir)$(IntermediateOutputPath)$(TargetFileName)"
DestinationFolder="$(ProjectDir)$(OutputPath)" />
<Exec Command=""H:\Visual Studio
2005\Projects\ApplicationName\ApplicationName\ListAll" "BeforePublish05AfterCopy"" />
<SAB_MsgBox Prompt="BeforePublish After Copy" />
<!-- -->
<CallTarget Targets="GenerateManifests" />
<Exec Command=""H:\Visual Studio
2005\Projects\ApplicationName\ApplicationName\ListAll"
"BeforePublish06AfterGenerateManifests"" />
<SAB_MsgBox Prompt="BeforePublish After GenerateManifests" />
<!-- -->
<CallTarget Targets="_CopyManifestFiles" />
<Exec Command=""H:\Visual Studio
2005\Projects\ApplicationName\ApplicationName\ListAll"
"BeforePublish07After_CopyManifestFiles"" />
<SAB_MsgBox Prompt="BeforePublish After _CopyManifestFiles" />
</Target>
The SAB_MsgBox task lets me pause the process until the time goes to the next minute which makes it
easier to see changes in the Date Modified in the output of the ListAll.cmd file. Both the
SAB_MsgBox task and the ListAll command would be commented out in normal usage.
ListAll contains:
IF %1. == . GOTO MISSING
H:
CD "\Visual Studio 2005\Projects\ApplicationName\ApplicationName"
DIR OBJ /ON /S > OBJBIN%1.LST
DIR BIN /ON /S >> OBJBIN%1.LST
GOTO EXIT
:MISSING
ECHO Operand Missing
PAUSe
:EXIT
I had to set signing to Delayed so I could run Dotfuscator and then sign the assemply using SN.EXE.
I have that working -- including regenerating the manifest files. The last problem was if I wanted
to skip the Dotfuscator (to be able to see what is happening in the installed version) the manifest
generation was skipped even though SN.EXE signed the file. From the output of the ListAll.cmd file
it appears that SN.EXE signs the file without changing its Date Modified timestamp. I had to add a
Touch task (included above).
I can now publish from within the IDE and have a Dotfuscatored, Strong Named application pushed to
the web site.
>Yes. Only documents related to MSBuild are provided. Our product team has
>confirmed that VS IDE relies mostly on MSBuild to build and publish an
>application.
The key word is MOSTLY. The VS IDE appears to invoke MSBuild at least twice during the process
before actually publishing the files to the web site. It may be more under certain conditions as I
had BeforeCompile invoked three to five time when running in the IDE and only once when trying to
use MSBuild via the command line. It is also runs differently depending on how it is invoked from
the IDE. Right click on the project and selecting publish produces different output than using the
Publish Now button.
Is there anyway to get the parameters passed to MSBuild from the IDE for each call? The interface
between the IDE and MSBuild should be clearly documented. For example, if you select Sign Assembly
without checking Delay Signing the information for signing the assembly is passed to VBC. It would
be helpful if there was a simply table that mapped each item in the Project property sheets to the
corresponding element in the project file or the corresponding parameter that the IDE passes to
MSBuild. This would greatly facilitate running the project file via MSBuild from the command line.
v-l...@online.microsoft.com (Linda Liu[MSFT]) wrote:
Linda Liu[MSFT]
Thank you for sharing how you successfully solve the problem!
> It would be helpful if there was a simply table that mapped each item in
the Project property sheets to the
corresponding element in the project file or the corresponding parameter
that the IDE passes to MSBuild.
I understand your concern. I suggest you to make a suggestion for this in
the Microsoft Connection web site:
http://connect.microsoft.com/VisualStudio/Feedback
Thank you for your contribution to our product!
If you don't have any question, I would like to close this issue.
Stewart Berman
I would still like to know why signing an application's executable doesn't change the Date Modified
for the file.
>I understand your concern. I suggest you to make a suggestion for this in
>the Microsoft Connection web site:
>http://connect.microsoft.com/VisualStudio/Feedback
>
Visual Studio 2005 is not supported there. I have hit a few bugs but am unable to report them via
Feedback. The worst one is that the IDE goes into a hard loop if I make changes to the main form
via Designer. For example, if I simply add a menu item and then press save the IDE goes into a hard
loop and I have to kill it through Task Manager. I have to make changes in Main by editing
Main.Designer.vb. (Takes me back to my C days before IDEs.)
The only way I can report bugs in Visual Studio 2005 is by providing a credit card number so
Microsoft can charge me for the privilege.
v-l...@online.microsoft.com (Linda Liu[MSFT]) wrote:
Stewart Berman
I think I have a fairly good handle on developing and publishing a ClickOnce application.
Test project is finished. Doesn't do much but it let me explore the ClickOnce process and PC based
VB.NET application process.
Description here: http://www.saberman.com/SABBackgroundSlideShow/
Thanks for your help and please close this issue.
v-l...@online.microsoft.com (Linda Liu[MSFT]) wrote:
Linda Liu[MSFT]
Ok, I will close this issue now. If you have any other questions in the
future, please don't hesitate to contact us. It's always our pleasure to be
of assistance.
Have a nice day.