Let's just say that I am foolish enough to code and distribute a free app to
the general public over the web.
What is the best (cheapest, smallest bandwidth, easiest to code) way to
publish updates to my .Net application?
I'd like to save bandwidth by only updating the changed portions if
possible.
Thanks!
jim
On Jan 30, 3:43 am, "jim"
> Let's just say that I am foolish enough to code and distribute a free app to
> the general public over the web.
>
> What is the best (cheapest, smallest bandwidth, easiest to code) way to
> publish updates to my .Net application?
>
> I'd like to save bandwidth by only updating the changed portions if
> possible.
>
> Thanks!
>
> jim
It depends a lot on your architecture and deployment. ClickOnce offers
automatic update functionality, but I have never used it so I can't be
of too much help there. Also, if you architectured the program with
dll's you could just release a new version of the dll. Besides that,
here are a few links you might want to read:
http://www.codeproject.com/KB/install/dotnetpatching.aspx
http://www.codeproject.com/KB/IP/ApplicationUpdate.aspx
http://www.codeproject.com/KB/install/DDayUpdate_Part1.aspx
I haven't read them, but they seem to be dealing with your topic.
Thanks,
Seth Rowe [MVP]
Cheapest is probably ClickOnce, it also requires no coding.
I don't know what sort of bandwidth it uses; but that would involve
comparing to another method of updating anyway.
--
Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote.
http://www.peterRitchie.com/blog/
Microsoft MVP, Visual Developer - Visual C#
"jim" wrote:
> Let's just say that I am foolish enough to code and distribute a free app to
> the general public over the web.
>
> What is the best (cheapest, smallest bandwidth, easiest to code) way to
> publish updates to my .Net application?
>
> I'd like to save bandwidth by only updating the changed portions if
> possible.
Jim,
I don't think ClickOnce (as mentioned in other threads) is a good idea
here. The reason for that is that you mentioned you are going to distribute
a free app over the web.
Because of this, you might run into issues in trying to public a
ClickOnce app on your hosting server (if you don't have a dedicated server,
you might have restrictions preventing you from publishing it).
Also, the model for upgrading the app becomes cumbersome. If you have
multiple versions, and you only want to distribute the changed portions, you
will have to make a patch for every upgrade of every previous version to the
current version.
In other words, if you released version 1.1, 1.2 and 1.3, and someone
installs 1.1, and wants to install version 1.3, you have to provide a
specific patch from 1.1 to 1.3, as well as 1.2 to 1.3.
Expecting the user to go through the patches manually will create a very
ugly user experience, and deter a number of people (it would deter me).
Because of that, for the audience you are targeting, it would probably
be a better user experience if you created an install package which will
remove previous versions of your program, and then do a full install of the
current version the installer represents.
--
- Nicholas Paldino [.NET/C# MVP]
- mvp@spam.guard.caspershouse.com
"jim"
news:YMWnj.62733$vt2.43850@bignews8.bellsouth.net...
> Let's just say that I am foolish enough to code and distribute a free app
> to the general public over the web.
>
> What is the best (cheapest, smallest bandwidth, easiest to code) way to
> publish updates to my .Net application?
>
> I'd like to save bandwidth by only updating the changed portions if
> possible.
>
> Thanks!
>
> jim
>
"Nicholas Paldino [.NET/C# MVP]"
message news:OAEh9Y3YIHA.3400@TK2MSFTNGP03.phx.gbl...
> Jim,
>
> I don't think ClickOnce (as mentioned in other threads) is a good idea
> here. The reason for that is that you mentioned you are going to
> distribute a free app over the web.
>
> Because of this, you might run into issues in trying to public a
> ClickOnce app on your hosting server (if you don't have a dedicated
> server, you might have restrictions preventing you from publishing it).
>
> Also, the model for upgrading the app becomes cumbersome. If you have
> multiple versions, and you only want to distribute the changed portions,
> you will have to make a patch for every upgrade of every previous version
> to the current version.
>
> In other words, if you released version 1.1, 1.2 and 1.3, and someone
> installs 1.1, and wants to install version 1.3, you have to provide a
> specific patch from 1.1 to 1.3, as well as 1.2 to 1.3.
>
> Expecting the user to go through the patches manually will create a
> very ugly user experience, and deter a number of people (it would deter
> me).
>
> Because of that, for the audience you are targeting, it would probably
> be a better user experience if you created an install package which will
> remove previous versions of your program, and then do a full install of
> the current version the installer represents.
>
>
> --
> - Nicholas Paldino [.NET/C# MVP]
> - mvp@spam.guard.caspershouse.com
I agree.
I think that a bootstrap application that mimics the actual appliation's UI
and performs the uninstall/install for the user would be the least
disruptive in perfroming updates to the app.
The only problem I have with this is that we will be doing LOTS of additions
in the first 3-6 months. Updates will be ready for release almost every
week (if the projected schedule holds up) - NOT including hotfixes to fix
what we screw up with this fast paced development cycle.
Most of the changes will be to our toolbox - adding more and more tools...as
fast as our bloody nubs can peck out and test the code.
Our toolbox options will change with user requests and with how the users
are seen to be using the application. It will be quite dynamic as compared
to other desktop applications.
So, we need to strike a balance. We have to get something out now (if you
wit until it is perfect it will never ship), and we have to be able to add
tools (and the code behind them) to our toolbox at will and drop hotfixes
like....well...like they're hot.
The user experience is the most important thing. That's the reason for the
constant updates and the reason I am leaning towards a bootstapped launcher.
But, I also don't want to delay the user from opening the app *too much*
with the constant updates.
Ahhh.....programming for the masses. You gotta love it.
jim
"Peter Ritchie [C# MVP]"
news:AED17E57-7DCA-4AA6-8640-0DF2736E4813@microsoft.com...
> Cheapest is probably ClickOnce, it also requires no coding.
>
> I don't know what sort of bandwidth it uses; but that would involve
> comparing to another method of updating anyway.
>
> --
> Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote.
> http://www.peterRitchie.com/blog/
> Microsoft MVP, Visual Developer - Visual C#
ClickOnce is the cheapest. Unfortunately it is also the msot restricitive
in terms of the .Net security model.
And, asking users to slosh through arcane instructions (to most of them
anyway) just to enable an app to save a file to the hard drive is not
something that we are comfortable with.
ClickOnce was a great idea (almost wet myself when I first heard of the
basic concept). Unfortunately, reality set in quickly upon realizing just
how basic the apps are that you can send over the internet with ClickOnce
without requiring end users to mess with stuff they are as apt to screw up
as get right.
Whatever happens, we don't want to be tagged as "the people that messed up
my PC" is a user screws around with .Net security and doesn't get it right.
Microsoft gets more thing *almost* right than any other company....ever.
And that's a shame.
Heck - activeX controls are more powerful (and easier to host) than
ClickOnce apps over the web.
jim
"rowe_newsgroups"
news:9a7eab19-6781-4259-af49-75a54f6f78f2@k39g2000hsf.google groups.com...
> On Jan 30, 3:43 am, "jim"
>> Let's just say that I am foolish enough to code and distribute a free app
>> to
>> the general public over the web.
>>
>> What is the best (cheapest, smallest bandwidth, easiest to code) way to
>> publish updates to my .Net application?
>>
>> I'd like to save bandwidth by only updating the changed portions if
>> possible.
>>
>> Thanks!
>>
>> jim
>
> It depends a lot on your architecture and deployment. ClickOnce offers
> automatic update functionality, but I have never used it so I can't be
> of too much help there. Also, if you architectured the program with
> dll's you could just release a new version of the dll. Besides that,
> here are a few links you might want to read:
>
> http://www.codeproject.com/KB/install/dotnetpatching.aspx
> http://www.codeproject.com/KB/IP/ApplicationUpdate.aspx
> http://www.codeproject.com/KB/install/DDayUpdate_Part1.aspx
>
> I haven't read them, but they seem to be dealing with your topic.
>
> Thanks,
>
> Seth Rowe [MVP]
I can speak for ClickOnce. It handles incremental updates automatically.
That's one of the main reason why my company uses it.
RobinS.
GoldMail, Inc.
"jim"
news:z_7oj.86285$L%6.78039@bignews3.bellsouth.net...
>
> "Peter Ritchie [C# MVP]"
> news:AED17E57-7DCA-4AA6-8640-0DF2736E4813@microsoft.com...
>> Cheapest is probably ClickOnce, it also requires no coding.
>>
>> I don't know what sort of bandwidth it uses; but that would involve
>> comparing to another method of updating anyway.
>>
>> --
>> Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote.
>> http://www.peterRitchie.com/blog/
>> Microsoft MVP, Visual Developer - Visual C#
>
> ClickOnce is the cheapest. Unfortunately it is also the msot restricitive
> in terms of the .Net security model.
>
> And, asking users to slosh through arcane instructions (to most of them
> anyway) just to enable an app to save a file to the hard drive is not
> something that we are comfortable with.
>
> ClickOnce was a great idea (almost wet myself when I first heard of the
> basic concept). Unfortunately, reality set in quickly upon realizing just
> how basic the apps are that you can send over the internet with ClickOnce
> without requiring end users to mess with stuff they are as apt to screw up
> as get right.
>
> Whatever happens, we don't want to be tagged as "the people that messed up
> my PC" is a user screws around with .Net security and doesn't get it
> right.
>
> Microsoft gets more thing *almost* right than any other company....ever.
> And that's a shame.
>
> Heck - activeX controls are more powerful (and easier to host) than
> ClickOnce apps over the web.
>
> jim
>
Obviously you needed to read Brian Noyes' ClickOnce book. We are using
ClickOnce very successfully. It installs the application into the user's
profile, so it does not mess with anything else on the user's computer, and
can't mess anything up. We are deploying part of DirectX with our
application, and it does not conflict with the user's version in any way,
shape, or form. You just have to know how to get it done.
RobinS.
Goldmail, Inc.
You are wrong about the updating capabilities and methodology of ClickOnce.
With ClickOnce, you deploy your updated versions to the same url as the
original, and when the user runs the application again, it checks and picks
up the latest version. You deploy the whole thing every time to your
webserver. When installing, ClickOnce checks the versions of any and all
included files, and only copies over the new ones that it needs.
You end up with multiple versions on your web server, but the most current
one is myapp.application, and that tells which version to actually install.
This means you can easily go back a version by copying one of the versioned
application files (like myapp.application_10_1_1_1, named that way bye
default), and you can remove old versions as you deploy more of them.
You can make the updates optional or required. You can make 6 updates in a
row optional, and then make the next one required. It's very flexible. If
you make them optional, it will come up and ask the user if he wants to
install it, or skip this version.
If you have problems, and you're putting out optional versions, the user can
even revert back one version using "add/remove programs".
ClickOnce by default deploys the files with the file extension "deploy", and
knows what to do with them when the user runs the deployment, which removes
the problem many web servers have with allowing files ending in dll, exe,
etc.
I recommend the OP try it out. It has been grossly misrepresented here. For
more info about ClickOnce, check out Brian Noyes' book about it -- it is
hugely useful.
RobinS.
GoldMail, Inc.
------------------------------------
"Nicholas Paldino [.NET/C# MVP]"
message news:OAEh9Y3YIHA.3400@TK2MSFTNGP03.phx.gbl...
> Jim,
>
> I don't think ClickOnce (as mentioned in other threads) is a good idea
> here. The reason for that is that you mentioned you are going to
> distribute a free app over the web.
>
> Because of this, you might run into issues in trying to public a
> ClickOnce app on your hosting server (if you don't have a dedicated
> server, you might have restrictions preventing you from publishing it).
>
> Also, the model for upgrading the app becomes cumbersome. If you have
> multiple versions, and you only want to distribute the changed portions,
> you will have to make a patch for every upgrade of every previous version
> to the current version.
>
> In other words, if you released version 1.1, 1.2 and 1.3, and someone
> installs 1.1, and wants to install version 1.3, you have to provide a
> specific patch from 1.1 to 1.3, as well as 1.2 to 1.3.
>
> Expecting the user to go through the patches manually will create a
> very ugly user experience, and deter a number of people (it would deter
> me).
>
> Because of that, for the audience you are targeting, it would probably
> be a better user experience if you created an install package which will
> remove previous versions of your program, and then do a full install of
> the current version the installer represents.
>
>
> --
> - Nicholas Paldino [.NET/C# MVP]
> - mvp@spam.guard.caspershouse.com
>
> "jim"
> news:YMWnj.62733$vt2.43850@bignews8.bellsouth.net...
>> Let's just say that I am foolish enough to code and distribute a free app
>> to the general public over the web.
>>
>> What is the best (cheapest, smallest bandwidth, easiest to code) way to
>> publish updates to my .Net application?
>>
>> I'd like to save bandwidth by only updating the changed portions if
>> possible.
>>
>> Thanks!
>>
>> jim
>>
>
>
"jim"
news:YMWnj.62733$vt2.43850@bignews8.bellsouth.net:
> Let's just say that I am foolish enough to code and distribute a free
> app to
> the general public over the web.
>
> What is the best (cheapest, smallest bandwidth, easiest to code) way to
> publish updates to my .Net application?
>
> I'd like to save bandwidth by only updating the changed portions if
> possible.
>
> Thanks!
>
> jim
Well, two out of three ain't bad.
The cheapest and easiest is to re-install the entire app. This is the
way most applications are updated via the web.
If you make sure that your website gives detailed information on the
reason for a new release and whether it is critical or not, the users
can decide whether it is worth upgrading. Other solutions are going to
increase the workload (and potential for error) on you, and more
importantly, the user.
..NET apps aren't that big compared to native code.
"RobinS"
news:fsidnaq7N5fW-zzanZ2dnUVZ_t-nnZ2d@comcast.com...
>
> "jim"
> news:z_7oj.86285$L%6.78039@bignews3.bellsouth.net...
>>
>> "Peter Ritchie [C# MVP]"
>> news:AED17E57-7DCA-4AA6-8640-0DF2736E4813@microsoft.com...
>>> Cheapest is probably ClickOnce, it also requires no coding.
>>>
>>> I don't know what sort of bandwidth it uses; but that would involve
>>> comparing to another method of updating anyway.
>>>
>>> --
>>> Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote.
>>> http://www.peterRitchie.com/blog/
>>> Microsoft MVP, Visual Developer - Visual C#
>>
>> ClickOnce is the cheapest. Unfortunately it is also the msot
>> restricitive in terms of the .Net security model.
>>
>> And, asking users to slosh through arcane instructions (to most of them
>> anyway) just to enable an app to save a file to the hard drive is not
>> something that we are comfortable with.
>>
>> ClickOnce was a great idea (almost wet myself when I first heard of the
>> basic concept). Unfortunately, reality set in quickly upon realizing
>> just how basic the apps are that you can send over the internet with
>> ClickOnce without requiring end users to mess with stuff they are as apt
>> to screw up as get right.
>>
>> Whatever happens, we don't want to be tagged as "the people that messed
>> up my PC" is a user screws around with .Net security and doesn't get it
>> right.
>>
>> Microsoft gets more thing *almost* right than any other company....ever.
>> And that's a shame.
>>
>> Heck - activeX controls are more powerful (and easier to host) than
>> ClickOnce apps over the web.
>>
>> jim
>>
>
> Obviously you needed to read Brian Noyes' ClickOnce book. We are using
> ClickOnce very successfully. It installs the application into the user's
> profile, so it does not mess with anything else on the user's computer,
> and can't mess anything up. We are deploying part of DirectX with our
> application, and it does not conflict with the user's version in any way,
> shape, or form. You just have to know how to get it done.
>
> RobinS.
> Goldmail, Inc.
Got a copy..... Upon looking at the code security section, it is going to
take a few reads to get down to the simple "How do I....." that I prefer.
For example "How do I enable full trust for my ClickOnce application -
without scaring the crap out of potential new users to both my app and
clickonce apps?" "How do I package 3rd party controls with my ClickOnce
application?" "How do I......."
Honestly, I don't give a rat's ass about the why and internal workings of
things unless I absolutely MUST know them. I am more interested in results.
Quick, verifiable, reproducable results.
I am certain that Brian is an authority on the subject of ClickOnce. What
Brian needs is an authority on simple, powerful writing that allows busy
people to scan and do as quickly as possible - especially with the harried
schedules of developers and non-developers that are tossed into that role.
My idea of the perfect book is a 2 part volume that has a "How do I...."
Part 1 for busy people that "just need it to work, and need it to work
now" - this is for the people hovered over by bosses that think writing code
is like writing an email. And, a "This is what you just did...." Part 2
that takes each "How do I..." in Part 1 and really gets into the how and why
of it. This section is for people that really like to know (and have the
luxury of extra time to study) the ins and outs of everything they do - and
for fixing the apps forced by those bosses that make Part 1 a neccessity.
At this point, it seems quicker to just write the damned thing as an
installable application and deply entire installs as needed.
It is not the man that knows it all that is king.....but the man that can
explain it to all such that they understand it quickly and for good.
jim
"jim"
news:UVqoj.88725$K27.79272@bignews6.bellsouth.net...
>
> "RobinS"
> news:fsidnaq7N5fW-zzanZ2dnUVZ_t-nnZ2d@comcast.com...
>>
>> "jim"
>> news:z_7oj.86285$L%6.78039@bignews3.bellsouth.net...
>>>
>>> "Peter Ritchie [C# MVP]"
>>> news:AED17E57-7DCA-4AA6-8640-0DF2736E4813@microsoft.com...
>>>> Cheapest is probably ClickOnce, it also requires no coding.
>>>>
>>>> I don't know what sort of bandwidth it uses; but that would involve
>>>> comparing to another method of updating anyway.
>>>>
>>>> --
>>>> Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote.
>>>> http://www.peterRitchie.com/blog/
>>>> Microsoft MVP, Visual Developer - Visual C#
>>>
>>> ClickOnce is the cheapest. Unfortunately it is also the msot
>>> restricitive in terms of the .Net security model.
>>>
>>> And, asking users to slosh through arcane instructions (to most of them
>>> anyway) just to enable an app to save a file to the hard drive is not
>>> something that we are comfortable with.
>>>
>>> ClickOnce was a great idea (almost wet myself when I first heard of the
>>> basic concept). Unfortunately, reality set in quickly upon realizing
>>> just how basic the apps are that you can send over the internet with
>>> ClickOnce without requiring end users to mess with stuff they are as apt
>>> to screw up as get right.
>>>
>>> Whatever happens, we don't want to be tagged as "the people that messed
>>> up my PC" is a user screws around with .Net security and doesn't get it
>>> right.
>>>
>>> Microsoft gets more thing *almost* right than any other company....ever.
>>> And that's a shame.
>>>
>>> Heck - activeX controls are more powerful (and easier to host) than
>>> ClickOnce apps over the web.
>>>
>>> jim
>>>
>>
>> Obviously you needed to read Brian Noyes' ClickOnce book. We are using
>> ClickOnce very successfully. It installs the application into the user's
>> profile, so it does not mess with anything else on the user's computer,
>> and can't mess anything up. We are deploying part of DirectX with our
>> application, and it does not conflict with the user's version in any way,
>> shape, or form. You just have to know how to get it done.
>>
>> RobinS.
>> Goldmail, Inc.
>
> Got a copy..... Upon looking at the code security section, it is going to
> take a few reads to get down to the simple "How do I....." that I prefer.
>
> For example "How do I enable full trust for my ClickOnce application -
> without scaring the crap out of potential new users to both my app and
> clickonce apps?" "How do I package 3rd party controls with my ClickOnce
> application?" "How do I......."
>
> Honestly, I don't give a rat's ass about the why and internal workings of
> things unless I absolutely MUST know them. I am more interested in
> results. Quick, verifiable, reproducable results.
>
> I am certain that Brian is an authority on the subject of ClickOnce. What
> Brian needs is an authority on simple, powerful writing that allows busy
> people to scan and do as quickly as possible - especially with the harried
> schedules of developers and non-developers that are tossed into that role.
>
> My idea of the perfect book is a 2 part volume that has a "How do I...."
> Part 1 for busy people that "just need it to work, and need it to work
> now" - this is for the people hovered over by bosses that think writing
> code is like writing an email. And, a "This is what you just did...."
> Part 2 that takes each "How do I..." in Part 1 and really gets into the
> how and why of it. This section is for people that really like to know
> (and have the luxury of extra time to study) the ins and outs of
> everything they do - and for fixing the apps forced by those bosses that
> make Part 1 a neccessity.
>
> At this point, it seems quicker to just write the damned thing as an
> installable application and deply entire installs as needed.
>
> It is not the man that knows it all that is king.....but the man that can
> explain it to all such that they understand it quickly and for good.
>
> jim
>
Maybe in order to understand how to implement it, you need the background
info he's providing in the book. Or you need to learn to skim. I skipped the
chapter on security completely the first time I read the book.
I deploy our app with full trust. Buy a security certificate and sign your
deployment so it doesn't say "unknown publisher".
For 3rd party controls, assuming you have the dll's and that's what you want
to deploy, I put mine into a folder called something like "3rdpartydlls"
under the main project. I then made sure my references pointed to those
specific dll's, and not to the same thing elsewhere on my machine. Then I
set "Copy Local" to true on the reference. The entry that shows up under the
folder in VS should be set to have a build action of "None" and
copy-to-output-directory set to "Do not copy". It will be included because
it is referenced.
Frankly, I found Brian's book very helpful, and was able to skim it for what
I needed to know, and go back for the more complicated stuff later as
difficulties arise. If you're not patient enough to do that, your loss.
Maybe you should write your own book. It's harder than you think.
RobinS.
GoldMail, Inc.
"RobinS"
news:UOGdnSQ7M8P-DT_anZ2dnUVZ_vqpnZ2d@comcast.com...
>
> "jim"
> news:UVqoj.88725$K27.79272@bignews6.bellsouth.net...
>>
>> "RobinS"
>> news:fsidnaq7N5fW-zzanZ2dnUVZ_t-nnZ2d@comcast.com...
>>>
>>> "jim"
>>> news:z_7oj.86285$L%6.78039@bignews3.bellsouth.net...
>>>>
>>>> "Peter Ritchie [C# MVP]"
>>>> news:AED17E57-7DCA-4AA6-8640-0DF2736E4813@microsoft.com...
>>>>> Cheapest is probably ClickOnce, it also requires no coding.
>>>>>
>>>>> I don't know what sort of bandwidth it uses; but that would involve
>>>>> comparing to another method of updating anyway.
>>>>>
>>>>> --
>>>>> Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote.
>>>>> http://www.peterRitchie.com/blog/
>>>>> Microsoft MVP, Visual Developer - Visual C#
>>>>
>>>> ClickOnce is the cheapest. Unfortunately it is also the msot
>>>> restricitive in terms of the .Net security model.
>>>>
>>>> And, asking users to slosh through arcane instructions (to most of them
>>>> anyway) just to enable an app to save a file to the hard drive is not
>>>> something that we are comfortable with.
>>>>
>>>> ClickOnce was a great idea (almost wet myself when I first heard of the
>>>> basic concept). Unfortunately, reality set in quickly upon realizing
>>>> just how basic the apps are that you can send over the internet with
>>>> ClickOnce without requiring end users to mess with stuff they are as
>>>> apt to screw up as get right.
>>>>
>>>> Whatever happens, we don't want to be tagged as "the people that messed
>>>> up my PC" is a user screws around with .Net security and doesn't get it
>>>> right.
>>>>
>>>> Microsoft gets more thing *almost* right than any other
>>>> company....ever. And that's a shame.
>>>>
>>>> Heck - activeX controls are more powerful (and easier to host) than
>>>> ClickOnce apps over the web.
>>>>
>>>> jim
>>>>
>>>
>>> Obviously you needed to read Brian Noyes' ClickOnce book. We are using
>>> ClickOnce very successfully. It installs the application into the user's
>>> profile, so it does not mess with anything else on the user's computer,
>>> and can't mess anything up. We are deploying part of DirectX with our
>>> application, and it does not conflict with the user's version in any
>>> way, shape, or form. You just have to know how to get it done.
>>>
>>> RobinS.
>>> Goldmail, Inc.
>>
>> Got a copy..... Upon looking at the code security section, it is going
>> to take a few reads to get down to the simple "How do I....." that I
>> prefer.
>>
>> For example "How do I enable full trust for my ClickOnce application -
>> without scaring the crap out of potential new users to both my app and
>> clickonce apps?" "How do I package 3rd party controls with my ClickOnce
>> application?" "How do I......."
>>
>> Honestly, I don't give a rat's ass about the why and internal workings of
>> things unless I absolutely MUST know them. I am more interested in
>> results. Quick, verifiable, reproducable results.
>>
>> I am certain that Brian is an authority on the subject of ClickOnce.
>> What Brian needs is an authority on simple, powerful writing that allows
>> busy people to scan and do as quickly as possible - especially with the
>> harried schedules of developers and non-developers that are tossed into
>> that role.
>>
>> My idea of the perfect book is a 2 part volume that has a "How do I...."
>> Part 1 for busy people that "just need it to work, and need it to work
>> now" - this is for the people hovered over by bosses that think writing
>> code is like writing an email. And, a "This is what you just did...."
>> Part 2 that takes each "How do I..." in Part 1 and really gets into the
>> how and why of it. This section is for people that really like to know
>> (and have the luxury of extra time to study) the ins and outs of
>> everything they do - and for fixing the apps forced by those bosses that
>> make Part 1 a neccessity.
>>
>> At this point, it seems quicker to just write the damned thing as an
>> installable application and deply entire installs as needed.
>>
>> It is not the man that knows it all that is king.....but the man that can
>> explain it to all such that they understand it quickly and for good.
>>
>> jim
>>
>
> Maybe in order to understand how to implement it, you need the background
> info he's providing in the book. Or you need to learn to skim. I skipped
> the chapter on security completely the first time I read the book.
>
> I deploy our app with full trust. Buy a security certificate and sign your
> deployment so it doesn't say "unknown publisher".
>
> For 3rd party controls, assuming you have the dll's and that's what you
> want to deploy, I put mine into a folder called something like
> "3rdpartydlls" under the main project. I then made sure my references
> pointed to those specific dll's, and not to the same thing elsewhere on my
> machine. Then I set "Copy Local" to true on the reference. The entry that
> shows up under the folder in VS should be set to have a build action of
> "None" and copy-to-output-directory set to "Do not copy". It will be
> included because it is referenced.
>
> Frankly, I found Brian's book very helpful, and was able to skim it for
> what I needed to know, and go back for the more complicated stuff later as
> difficulties arise. If you're not patient enough to do that, your loss.
> Maybe you should write your own book. It's harder than you think.
We were justsuitting around talking about that. I do think I'll try my hand
at writing my own book
Results are what counts - not how much you memorize or can regurgitate on a
test. The world is results-based. They don't care what you know...it's
what you can do for them that feeds the ducks.
jim