Smart Client Deployment

[Brian Sokolnicki]

I hope this is an easy question to answer.

In developing a smart client application, I'm lead to beleive that only
assemblies that have changed get updated during the next time the
application runs. But if you have a assembly that is referneced by other
assemblies, don't they need to get recompiled which changes there version
which in return everything needs to get downloaded again.

Can somebody please explian if this is true or not.

Thanks.

 

[Jeffrey Tan[MSFT]]

Hi Brian,

Thanks for your post!

Can you confirm if you are using .Net2.0 ClickOnce, or you are only using
..Net1.1 No touch deployment? They are both called Smart Client

I assume you are using .Net2.0 ClickOnce since it is the more popular
approach.

Each version of .Net ClickOnce application will have a separate folder. For
example, there are 4 versions of application, there will be 4 folders with
name from WinformTest_1_0_0_1 to WinformTest_1_0_0_4. Also there are 4
application manifest to describe the 4 versions application.
After publishing, all the assemblies and components will be wrapped in a
setup.exe.

Whether the client installed application will be updated depends on if you
have published a new version. If you modified certain assemblies in the
application in server, you may choose to re-publish the application, which
will cause a newer version of folder/manifest to be created in server and
the setup.exe be substituted by new one. Then when the client application
lauches, it will check if there is any newer version of application
manifest exist, if so, it will download the new version and use the new
application.

Hope this helps. If I have misunderstood your concern, please feel free to
tell me, thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Brian Sokolnicki]

Yes, I'm refering to the .Net framework 2.0 and ClickOnce. So, If I
understand you correctly, everytime I publish my application for
installation, the client will check for a new version and if needed,
download the entire application, not just the modified assemblies.

On a side note, what makes the application a smart client? Is there a
beneift to creating many assemblies, or keep everything inside a single
..exe?

Thanks for your reply.

 

[Jeffrey Tan[MSFT]]

Hi Brian,

Thanks for your feedback!

Yes, you are right. Per your interest, I will provide some deeper
background information regarding ClickOnce.

The client installed menu item in the Start menu is just a shortcut to the
server side application manifest file. You may use notepad.exe to open the
shortcut, you will get something like this(my ClickOnce application is
named WinformTest):
http://msjeff1/WinformTest/WinformTest.application#WinformTest.application,
Culture=neutral, PublicKeyToken=c64e81645363ad96, processorArchitecture=msil

Also, the client .Net Framework2.0 will use a special way to run the
*.application, you may view it in Explorer->Tools menu->"Folder
Options.."->"File Types"->"Application: Application Manifest"->"Advanced
Button"->"open"->"Edit...". You will see that the client machine uses the
following action to run *.application file:
rundll32.exe dfshim.dll,ShOpenVerbApplication %1

%1 is the input parameter, which is
http://msjeff1/WinformTest/WinformTest.application in our case. So the
client use a dfshim.dll to run parse the server side
http://msjeff1/WinformTest/WinformTest.application file.

*.application file is a xml manifest file, which describes the ClickOnce
application information, and points to other most updated version of
ClickOnce manifest, such as WinformTest_1_0_0_4.application.

In server side, it is informative to give a look to the ClickOnce
application folder. As you can see, all the Exe and Dll assemblies will be
wrapped with a single setup.exe. So whenever the client dfshim.dll parses
the WinformTest.application, it will only case about the ClickOnce publish
version, it has nothing knowledge about if the assemblies embeded in the
setup.exe are changed. Once you deployed a new version, dfshim.dll will
detect this and download the setup.exe on the fly. Since a single PE file
can not be parse separately, the client will download the entire setup.exe
and run it locally. If you are curious, the installed application will be
unzipped in a temp folder, which is your user account profile folder,
something like this:
C:\Documents and Settings\jetan\Local
Settings\Apps\2.0\YYW1CTKJ.X14\OCHAAA0G.PQ3\winf..tion_c64e81645363ad96_0001
..0000_dabbedee3d3fc8dd

The path should appear different on your machine, however, you may follow
the path logic and find the temp folder yourself.

For your second question, the answer is to turn a normal .Net2.0 winform
application into a ClickOnce featured one, the VS2005 IDE will create the
application manifest on the fly, and it will wrap all the assemblies into a
single setup.exe. Anyway, VS2005 IDE will help to take care of these steps.

Hope this helps. If you still have anything unclear, please feel free to
tell me, thanks!

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Brian Sokolnicki]

Your answer has helped, but I don't think you answered my last question
which was:

Is there a beneift to creating many assemblies (seperating forms, etc), or
keep everything inside a single .exe?

Thanks....

Yes, I'm refering to the .Net framework 2.0 and ClickOnce. So, If I
understand you correctly, everytime I publish my application for
installation, the client will check for a new version and if needed,
download the entire application, not just the modified assemblies.

On a side note, what makes the application a smart client? Is there a
beneift to creating many assemblies, or keep everything inside a single
.exe?

Thanks for your reply.

Hi Brian,

Thanks for your post!

Can you confirm if you are using .Net2.0 ClickOnce, or you are only using
Net1.1 No touch deployment? They are both called Smart Client

I assume you are using .Net2.0 ClickOnce since it is the more popular
approach.

Each version of .Net ClickOnce application will have a separate folder.
For
example, there are 4 versions of application, there will be 4 folders
with
name from WinformTest_1_0_0_1 to WinformTest_1_0_0_4. Also there are 4
application manifest to describe the 4 versions application.
After publishing, all the assemblies and components will be wrapped in a
setup.exe.

Whether the client installed application will be updated depends on if
you
have published a new version. If you modified certain assemblies in the
application in server, you may choose to re-publish the application,
which
will cause a newer version of folder/manifest to be created in server and
the setup.exe be substituted by new one. Then when the client application
lauches, it will check if there is any newer version of application
manifest exist, if so, it will download the new version and use the new
application.

Hope this helps. If I have misunderstood your concern, please feel free
to
tell me, thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no
rights.

 

[Jeffrey Tan[MSFT]]

Hi Brian,

Thanks for your feedback!

Sorry, I am not sure if I understand you completely. After give it a second
reading, I assume that you are asking that whether it is better to separate
the application code in several referenced dll assemblies than include all
the code in a single .Net exe assembly for ClickOnce deployment. If I have
misunderstood you, please feel free to tell me.

In original design, since all the deployed version of ClickOnce application
will be downloaded on update, I do not think there is any performance
difference between using a single Exe or separating it into several Dll
assemblies from ClickOnce's perspective. However, besides ClickOnce, from
Application maintaince perspective, I think it should be better to embed
some of the tool classes within a namespace and compile in a Dll
assembly(that is another project in VS2005). This is easier to maintain and
keep your application modular. As you can see, .Net Class library also
keeps different classes in separate assemblies and deploy in GAC.

After performing some research, I found that recently, ClickOnce documented
a new feature named "File Patching". This new feature will check hash
signatures of the files specified in the application manifest for the
current application against the signatures in the manifest for the new
version at update time. And it will only download all of the files for the
new version of the application unless the files have changed.

Based on this new feature, it is a good idea to separate the application
into several parts, and only modified parts will be downloaded on need.
Unfortunately, VS often cause the same assemblies (exacly same source) to
have different hashes, so all assemblies will be downloaded to the client,
although only a few assemblies may have changed. So this feature will
appear to be useless for VS2005 building. Below 2 articles show more
information regarding file patching:
"How ClickOnce Performs Application Updates"
http://msdn2.microsoft.com/en-us/library/ms404267.aspx
"File Patching"
http://blogs.msdn.com/saurabh/archive/2006/01/25/517613.aspx

So if you want to make use of this feature, you have to build the updated
files in the project using commandline tool, and publish it manually, which
is bothersome.
If you are curious, below articles demonstrate the steps regarding
deploying the ClickOnce application manually without using VS2005:
"Building ClickOnce Applications from the Command Line"
http://msdn2.microsoft.com/en-us/library/ms165431.aspx
"Walkthrough: Deploying a ClickOnce Application Manually"
http://msdn2.microsoft.com/en-us/library/xc3tc5xx.aspx

Finally, with the above analysis, the answer to your question is: normally,
separating the application in several modules/assemblies is better than
including them in a single exe.

Hope this reply answered your questions!

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
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.