In my tutorial yesterday here at DevConnections I tossed the slides for the last half (those are for your reference) and basically spent the time demonstrating varioius aspects of ClickOnce: deployment, versioning, security, download on demand, globalization and offline data deployment. Whew, even without slides that was a lot to cover, and we opened many a can of worms that just leads to additional questions on the entire lifecycle of a smart client app deployed with ClickOnce.

One thing that really hit home is the “rights” users have to install applications. There are a variety of answers to that question, some of which were only vaguely answered in our discussion, and one item I wanted to follow up on...which I did with my colleague Brian Noyes.

Q. Who can install a click once application?

Any user can click a link to a ClickOnce application and install the application. If the appilcation requires greater trust than the zone they are installed from will grant (Intranet, Internet, My Computer) they will be prompted to approve the installation.

HA! That's that part I wasn't expecting (thanks Brian)...because I thought that ClickOnce was secure by default, meaning...users can't just click “ok“ to accept the download and elevation of application privileges...apparently I'm wrong...and I could swear I remembered speaking to someone “who knew“ about this in the past...but my memory may fail me...too much stuff in there I guess.

Q. What's the prompt for?

The download prompt is for one thing only: do you want to elevate security of this application you are downloading, beyond the security settings for its zone?

Are you sure? Are you REALLY sure?

And away we go, the app gets all the security it needs to run...that is, if there is sufficient permissions to complete the installation...

Q. Are users ALWAYS prompted to elevate security?

They are prompted every time the application is updated if it requires additional permissions beyond what the zone allowed.

UNLESS...the certificate is installed in the trusted publishers section of the certificate store, and if the issuer of the certificate is installed in the trusted roots section. Administrators can push the certs out to machines within the domain so that users are not prompted to elevate security for trusted publishers.

For non-trusted publishers, users will continue to be asked...WHAT??!? Yep, users by default have the right to “decide“ if they want to trust an application...and yes, it could be an application that when run deletes that special project they have been slaving over...or some other malicious behavior... and all because they were asked a question to which they responded...

duh...ok!

Q. Can administrators protect users from downloading untrusted applications?

Yes. If the prompting behavior is turned off, only applications that are trusted (cert has been installed) will be allowed to elevate security. Other apps can only run within the confines of the zone they belong to. So, if you install the application with an MSI, you get My Computer zone, and that grants full trust by default. Internet or Intranet downloads are granted less.

To turn off prompting behavior, set up the registry key:

To make life difficult for users? no

To make life difficult for Mort? no

To make it difficult to accidentally trust a malicious third party and give them full access to the machine? yes, absolutely

So, administrators get your SMS push ready and get that registry setting up and running...pronto! Unless you don't concern yourself with the users ability to install apps to the corporate domain.

Conclusions:

• by default anyone can install an application and elevate trust unless admins turn off the prompting features
• applications that have publisher certificates installed are trusted to elevate security
• application installations over the Web or via MSI still may need administrative if the bootstrapper calls for adding components to the GAC, or downloading SQL Server Express which requires an admin as well...so ClickOnce is not necessarily removing the pain of installing complex applications...but it sure makes it easy for apps that don't require admin installation privileges
• in any case, once installed updates that don't bootstrap additional functionality that requires admin installation rights...can be easily handled by any user

Hope this is helpful to those that were new to ClickOnce...since we really couldn't get through all the nit picky details in my talk.

Please visit my collegue Brian's talk tomorrow for more:

Wed 2:00-3:15pm - VSM351: Secure Smart Client ClickOnce Deployments

Unless you want to come to my talk on Indigo/WCF security:

Wed 2:00-3:15pm - VID304: Indigo and Security: Experience the Magic

See you around!

I decided to get BlogJet working for my Dev Connections posts…in honor of the Smart Client tutorial I’m giving Monday afternoon. In fact, if you are wondering why I (once again) went dark on posting to the blog for a while, well, I ended up getting an extra WCF slot at the conference, along with my 5 other talks (now 6!) and tutorial…so it has been busy busy busy as usual…getting ready to head to Vegas…after all, I have to try and enjoy some time at the black jack table too!

Speaking of black jack…maybe you saw in my latest post I lost bad in the Microsoft After Dark game…but it was for a good cause…I’ll do much better in Vegas I think, I’m more careful with my own money!

So, if you are coming to Dev Connections (I don’t see why you wouldn’t, it is now the biggest and best independently run Microsoft technologies conference out there!!!) here’s what I’ll be doing…come by and say hello…maybe give me some blackjack tips!

Here are my sessions at the conference…whew…this one is going to be busy busy busy…

Monday, November 7th

VPR203: Return of the Smart Client – What the heck do I do now? (1:00 PM - 4:00 PM)
Before the Web took over, developers spent their time designing, developing and building deployment strategies for rich client applications. End-users expected that rich user interface where tab-order and keyboard-only access was perfectly tuned, and perfectly tailored controls delivered functionality and ease-of-use. At first, the masses cringed at the less functional Web experience – and then ASP.NET came along making it incredibly easy to deliver a fairly rich experience, deployed to any Internet-connected PC. Now, we face a new paradigm shift. Users want it all: rich, user-friendly interfaces; no-touch deployment; automatic updates; offline work capabilities with applications that can later connect to central data stores. The Smart Client experience promises to deliver all of these requirements and more – but, we are entering a new phase where developers have to re-acquaint with best practices for rich client user interface design, and deployment and update strategies. They also have to learn how to handle the complexity introduced by supporting offline functionality, and hosting services for connected synchronization.  This session will review the concepts every developer should know to handle the return to the new thick smart client.

Tuesday, November 8th – MICROSOFT DAY!!!

Wednesday, November 9th

VPO357: Best Practice Approaches to .NET 2.0 Localization Architecture
When the .NET Framework was released, a new paradigm for localization architecture was born – simplifying some of the tedium of loading and managing resource lifetime, and selecting the best match for the user’s selected culture at runtime. Through IDE integration, robust assembly deployment and versioning features, and built-in support from localization class libraries, both Windows and Web applications were more easily localized. Built on this strong foundation, new localization features have been introduced with .NET 2.0 to bringing strongly typed resources, tighter IDE integration, and a much better localization story for ASP.NET applications. In this session you will be provided with a step by step, best practices approach to localizing your applications. You’ll learn how to control culture selection, how to work with XML resources and satellite assemblies, and see demonstrations of best practice deployment models.

VID304: Indigo and Security: Experience the Magic
The Indigo platform will unify our programming model for how components communicate: be they distributed or not, accessible beyond firewalls, or available through interoperable interfaces. Transport level and SOAP message security features, like other aspects of Indigo, can be enabled through XML configuration or programmatically through the Indigo API layer. In this session, you’ll learn the difference between single hop and message level security; how to apply security through endpoint binding configuration and behaviors; and see first hand how quickly you can secure your messaging layer. More importantly, you’ll see demonstrations that illustrate the amount of security goo that is encapsulated in the Indigo plumbing, in particular the elegance of its Web services security implementation which shields you from the XML that handles policy exchange, message authentication, integrity, confidentiality, and key exchange.

APF301: Performance Tuning and Monitoring your ASP.NET Applications
Sometimes the smallest details can make all the difference. This statement is true also of ASP.NET application performance. This session will provide you with a checklist designed to help you squeeze every dime of performance from your applications. You’ll learn techniques for reducing pressure on the garbage collector, best practices for state management, and how to reduce page load footprint. In addition, you’ll learn how to employ output and data caching mechanisms, leverage database caching, trigger batch site compilation, and avoid common pitfalls. Lastly, you’ll see how to leverage performance counters to baseline site performance and monitor statistics to meet service level agreements.

Thursday, November 10th

VID307: Designing Services with Indigo (Windows Communications Framework)
Services are the natural evolution of distributed components and RPC, providing greater possibilities for reuse and distribution from earlier component-oriented approaches. The Windows Communications Framework (WCF) introduces interesting possibilities for enterprise system design, specifically with regards to service design. Services are not RPC or Remote objects however they do solve the same problems. With WCF a service design approach applies to accessing functionality near or far, and satisfies the same implementation goals of Enterprise Services, Remoting and Web Services all in one. In this session you’ll see several examples of exchange patterns and transfer modes and see how to apply WCF principles to system design. You’ll learn how various WCF contracts and configurations can be applied to specific exchange patterns, how application-level messaging improves upon the parameter list approach, and see how common enterprise system design practices can now be more easily approached with the progressive service design and distribution support of the WCF.

ADX352: Beyond Drag & Drop Data Access: How to Decouple ASP.NET 2.0 Data Binding from Presentation
You can build data-centric Web sites in fewer steps than ever before with ASP.NET 2.0, but as always this can lead to poor design practices. This session first shows you how to leverage Server Explorer to quickly build prototypes of your data-bound Web pages, and subsequently shows you how to shuffle generated code into appropriate layers to promote decoupling and reusability, distribution and scalability, and reduction of maintenance overhead. You will see examples that employ the richness of the new GridView and DetailsView controls; learn best practices for employing data source controls to support decoupled two-way data-binding; learn how to employ data caching for performance; and techniques for storing and encrypting connection strings – all while maintaining a level of re-use and maintainability.

AGN351: 10 Essentials for a Professional ASP.NET 2.0 Application
Every ASP.NET application should be designed with a few essential requirements in mind. With the release of ASP.NET 2.0, developers need an updated checklist for constructing applications that follow some simple best practices. In this session, you'll be provided with 10 essential guidelines for  developing professional ASP.NET 2.0 applications, including best practices for page layout and design, navigation, error handling, caching, state management, authentication and authorization, configuration and encryption, component design and deployment, component security and sandboxing, and more. At the end of this session, you'll have access to samples that demonstrate each of these guidelines, with some reusable application templates to help you build secure, maintainable and professional ASP.NET 2.0 applications.

Feel free to ask questions about what I’m covering in more detail…or tell me what you are hoping to get out of any of these sessions you are attending…see you in Vegas babies!

I had the distinct honor to sit at the blackjack tables at Microsoft Studios in Redmond…just a few weeks ago. This event – called “Microsoft After Dark” – is in honor of the upcoming launch this week in San Fransisco. Basically, we chatted a bit about the products tied to the launch, and I was commissioned to “ask the tough questions” that our clients have been wondering about…so the heat was on, hot studio lights, hot topics, and hot competition at the tables…WHEW!

Of course, I should have known I was doomed when I opened the game saying something along the lines of “I’m going to crush you all…”. THAT was a mistake…because with $100,000 to play with (about 1000x more than I would ever consider bringing to the blackjack table) I figured…why not take some big risks…

The real problems started once I decided to up my bet to $50,000, and I had a PERFECT hand for double-down…argghh…and the dealer didn’t bust!!! I lost almost everything right there…oh well…ahem…letting…the VPs win was probably strategically smart given I was kind of pointed with my questions…and you know they had great answers for all of them :)

I’m afraid to watch this…so let me know what you think of it…

Speaking of Vegas…Dev Connections is coming…next week…and many of us are going to blog about our talks and sessions…plus…I’ll definitely try my hand at blackjack with my buddy Kimberly Tripp…join us :)

There have been a few more updates to our architecture podcast (I mentioned if first here: http://www.dasblonde.net/PermaLink.aspx?guid=9a692932-8a4c-47b1-b780-7db4bd1cb83b)...

We have one more round of comments for the 4th podcast to go live...and I think that will wrap up the podcast on WS*...but there will be more podcast in store. Check out the latest here:

http://www.microsoft.com/architecture/default.aspx?pid=share.podcast&abver=FEEB2E89-4412-4C58-A7F8-9B2CA0E0BDAC

What did you think about this discussion, and its flow. It was kind of interesting, we each recorded our comments over the phone, separately, in response to one another...I thought it was an effective way to get collect our opinions, and it didn't take much time to do (important when you are travelling, busy, deadlines, etc).

I can't wait to see the next set of topics and speakers...

Never ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever write service contracts and implementations inline.

With the PDC bits for WCF, using the Indigo Service template is like opening a box of chocolates...you never know what you'll get...IService, IMyService, IIndigoService...but that's just Beta stuff...

For Web sites the template generates the .svc endpoint and service implementation, for other project types it generates only the service implementation. Normally the service implementation would be in a .cs or .vb file (pick your language)...and this is true in all cases but one: adding a new Indigo Service to an existing Web site project in Visual Studio.

This template is evil...it creates inline code like this, with all the implementation in the target IIS endpoint file:

<%@ Service Language="C#" Class="IndigoService" %>

using System;
using System.ServiceModel;

[ServiceContract()]
public interface IIndigoService
{
    [OperationContract]
    string MyOperation1(string myValue);
}

public class IndigoService : IIndigoService
{
    public string MyOperation1(string myValue)
    {
        return "Hello: " + myValue;
    }
}

Now if I want to host this service outside of this Web site application I'll have to copy the service code into another file somewhere, or migrate this code to use a class library and share it. Why would I not just create the service in the class file from the beginning?

This may change before release...but just in case bookmark this post ...

Getting back to my earlier brain dump on the many ways you can create WCF services today...I have uploaded two samples:

The first sample is a solution with three projects: service, host and client. The service is a class library with a HelloIndigo.Service implementation, the host is a console application that initializes the ServiceHost for the service (self-host over HTTP), and the client consumes the service. ServiceFromScratchConfig.zip (54.5 KB)

THe second sample is a solution with two projects: a Web site created from the Indigo Service template, and a client to consume the service. The Web site acts as the host for the service (through IIS) but actually references the HelloIndigo.Service from the previous example. IISHostedService.zip (22.11 KB)

Same service, two hosts with possibly different bindings, behaviors, instancing.

If you always designer your services to be “moveable“ you will have an agile service-oriented system on your hands. The service contract and implementation (as expected) does not change, that should be appropriately versioned once it has been published. Oh, and guess what? Since the service is contained in a separate class library (assembly) it can be versioned appropriately with CLR versioning as well as contract versioning semantics.

So I have now explained why you should never use the Indigo Template “as is” when you build Web site, console, class library, or other applications that contain or host services. Sorry...templates are for kids...

I had several conversations this weekend with Steve Swartz (one of my favorite people, not just because he's smart, but he's a really cool guy too!) about best practices in various aspects of the service model. I'll eventually get a chance to blurt all of my thoughts on this (and confirmations a-la Steve) but let's start with the subject: base address and endpoints...how “should” it work?

Consider this example that creates a new self-hosted service with a base address and endpoint Uri as shown here hard-coded:

Uri baseAddress = new Uri("http://localhost:8000/HelloIndigo");
using (ServiceHost host = new ServiceHost(typeof(HelloIndigo.Service), baseAddress))
{

host.AddEndpoint(typeof(HelloIndigo.IService), new BasicHttpBinding(), new Uri("http://localhost:8000/HelloIndigo/Service"));

host.Open();
Console.ReadLine();
host.Close();
}

Seems harmless, and it will work. Clients will bind against the target Uri of the endpoint:

http://localhost:8000/HelloIndigo/Service

But the truth of the matter is that the base address should be relied on as the...well as the base address for all endpoints that share the same protocol, port, etc. In the above example that would suggest that when I add an endpoint to the service host, I should only submit “Service“ as a string (something you can do with one of the overloaded methods for AddEndpoint):

host.AddEndpoint(typeof(HelloIndigo.IService), new BasicHttpBinding(), "Service");

The same goes for declarative configuration for the service host, no need to specify the complete Uri, it will be inferred from the base address:

<service type="HelloIndigo.Service" >
  <endpoint address="Service" contract="HelloIndigo.IService, HelloIndigo" binding="basicHttpBinding" />
</service>

This makes your services more configurable, modify the base address and relative Uri will follow suit.

I thought I'd share this observation in the interest of coding practices for the WCF. For client applications invoking services, you'll see lots of samples already out there that use the following syntax:

ChannelFactory<IService> factory = new ChannelFactory<IService>("");
IService proxy = factory.CreateChannel();

string s = proxy.HelloIndigo();

If you weren't at the PDC, you can still get the latest WinFX bits, with the latest drop of WCF and WPF:

http://www.microsoft.com/downloads/details.aspx?familyid=ffd636f0-86e9-41e8-9e1c-100a4cc4888f&displaylang=en

Of course you need MSDN subscription to install the latest Visual Studio 2005 bits on top...but the RC1 candidate is available up there, so I recommend you use that...apparently it only runs with Beta 2, so you can't work with the latest and greatest 2005 bits today and get WinFX running.

Do this if you want to be able to run any code samples I post on Indigo...er...WCF WCF WCF WCF...

ADDING MORE INSTRUCTIONS

I found a great blog post explaining all the steps for PDC DVDs or downloaded bits here: http://www.longhornblogs.com/rrelyea/archive/2005/09/16/PDC2005Software.aspx

These are the download instructions from Rob Relyea's blog:

1. Operating System Required - Windows XP SP2 or Windows Vista 5219 (not Windows Vista beta1!)

2. WinFx CTP installation
This installs WinFX on the machine...end users will need this done.
WPF (fka "Avalon"), WCF (fka "Indigo"), and .NET Framework 2.0 all get installed with an integrated setup.

3. Visual Studio (Beta 2!!!)  (or you can also install Visual Basic Express  or VC# Express - just make sure it is "Beta 2"!)  Sorry, there is currently no build of WinFX that is compatible with RC or RTM builds of VS!
Once the install is done, make sure you do step 2 of the VS setup...install Help content - use it offline if you want it to work its best with WinFX SDK content to come later.

4. Windows WinFX SDK
This installs a ton of help content (samples, documentation) and some great tools (xamlpad, etc...)

5. VS Extensions for WinFx
This installs Project Templates and Item Templates for Visual Studio.

Sometimes it is really helpful to have different ways to build things...like WCF services for example...I can approach it from many different starting points. If I know I am going to host my services as part of a Web site/application...I might start from a different path than if I was building a truly service-oriented application that may or may not be always exposing services over HTTP and/or through IIS.

So you can do any of the following to create a service:

 a)       Create a new Web site project using the Indigo Service template and selecting HTTP (creates an IIS virtual directory for you, that's great!)

b)       Create a new Web site project using the Indigo Service template and selecting File System (this creates a file-based Web site, no IIS virtual directory, hosted with Cassini Web server)

c)       Create a new Class Library project then add an Indigo Service template item to it (no virtual directory is created for you, and no .svc endpoint is created...because the idea here would be to host this service “wherever you like“)

d) Create a new Console Application project then add an Indigo Service template item to it (no virtual directory or .svc but you can add self-hosting code to this application, coupling the host and service in one)

Some observations:

Option a) is useful for testing IIS services because it quickly generates a project that and creates the appropriate IIS virtual directory.

Option b) is problematic for a few reasons. First because in general, Cassini testing does not yield the same results as IIS-hosted testing when we’re talking about anonymous vs. authenticated access. Second because it requires NTLM authentication by default, requiring extra steps to enable access to your services on the development machine (I'll make a separate post on this)…possibly settings that will leak into deployment configs for QA and production if not caught. Whenever possible I think we should develop in the environment we will deploy in.

Both a) and b) have another drawback, that the service interface now gets lumped into the deployment of the ASP.NET Web site (the project it belongs to). That means either deploying source (hopefully no one will really deploy source in ASP.NET 2.0...just because you can) or precompiling the site (so now the code for the service is lumped into the ASP.NET application DLLs and it must now be versioned with those DLLS). This tightly couples the service (which should be an agile component of a system) to the ASP.NET application it is exposed through. I recommend there NOT be a template for creating indigo services with Web sites for this reason…because it moves you away from a pure service-oriented design.

Option c) is best because it implies that the service interface is part of a component that can be distributed and used by either an ASP.NET site, or a self-hosting environment, but coupled to neither.

Option d) couples the service to the host, nice for demos, not practical in deployment.

Of course, we always want tools for testing, that will make us quickly productive, and for that reason I say perhaps we are missing a few things. If we can have templates for services exposed as part of Web sites ( a) and b) ), we should also have template for creating self-hosted console services ( d) ), or IIS hosted class libraries ( c) with a twist ). The last item there is what we are missing perhaps, just in productivity terms:

e) Create a new Class Library then add the template item for IIS Hosted Indigo Service. This would create the IIS vdir and give us the darned .svc file for our class library, maybe even set the Build directory to \bin instead of \bin\debug or \bin\release so it will work without editing that.

Of course e) goes against my initial argument -> to force developers to build services in a service-oriented and decoupled manner...which would mean get rid of all but c) and watch people scream. I think what we'll need instead is a) through d) (plus e) if I get my wish) and we'll need to educate people why real services should be designed with c) because you know that a million and one code samples are already flying out to the Web that don't do c).

I'll post some samples separately, I wanted to get my rant out first. That feels better.

A long time ago Benjamin Mitchell told me about this tip...and I recently shared it with a few others...so I thought I'd post it for the entire world that reads my blog...

If you turn on word wrap (Tools->Options->Text Editor->All Languages, select Word Wrap and show glyphs), you shouldn't have to say things like this during your code presentations:

As you can see here...oh...wait...let me just scroll over a bit so you can see the rest of this statement...there...oh...wait...just a little further...there...ok, just a liiiiittle further...ok, can you remember all that? Good.

Keving Boyle, one of my local Microsoft Architect Evangelists makes an interesting observation here...

http://blogs.msdn.com/socalarchitect/archive/2005/09/23/473399.aspx?CommentPosted=true#commentmessage

and I'm not surprised because I still hear from a lot of companies that need to get started with Web Services 101. SOA just sounds like this big huge ominous endeavor if you listen to all the buzz out there...yet it should be very simple in my opinion.

OOP to classes is like components to applications is like services to systems

The question is of when an “application“ becomes a system, and that is a question of composition, complexity and distribution.

Notice you did not see the term “web services“ above. Web services are NOT a requirement of SOA, there are an interoperability facilitator.

Enterprise systems should be designed so that major chunks of functionality can be moved, distributed, refactored, replaced with alternate application or vendor sources...without tumbling down the entire system. Today's system is no longer a single monolithic endeavor by a single vendor. We are now in the business of building composite systems that comprise many applications or feature sets that are respectively built by appropriate domain experts. So, systems must be sure that major sources of functionality are not tightly coupled. Major features become “services“. Each “service“ can receive inputs, or return outputs...and everything that happens in the middle should be completely independent of the rest of the application (black box). That means I should be able to move the service to another machine, another vendor and still have things work just fine so long as the location can be found. So, a service is designed to use its own tables, configure its own file IO directories, and manage all other resources needed to perform its function. That does not mean there is a different database for every service in an application. It just means that the service is programmed not to depend on another services table structure. Use the same database, use a different database, it should not matter to the application as a whole because the service maintains its own configuration.

Consider this progression.

An application that logs incoming Web service requests, records a transaction, and shoots off a request to generate a PDF from the XML.

The functionality that logs messages doesn't have to be on the same tier, and the application may leverage another application to do the work...therefore that is a service (logically speaking):

The transaction logging activity is a core part of the application, but could later be distributed therefore that can be considered a logical service as well. In particular the PDF generating functionality could receive XML inputs, and be considered a separate service as well:

But, let's not think small. This entire system could be considered a service to another application that requires PDF generating and transaction reporting activities. In this example, the system is a certificate issuance system (from a system I designed for the insurance industry years ago) - so that would be the purpose of this interoperable service endpoint:

SOA is an approach to system design that has been implemented in systems of many differing technologies in the past, that makes a business more agile. New technologies are making SOA easier to implement, Web services make SOA interoperable, but it is really about designing enterprise systems so that there is an appropriate level of configurability and reuse at the outer "service" or "functionality" layer.

Indigo (WCF) will just make the implementation of services a natural part of system development.

What do you think? Is SOA too confusing?

Microsoft is sponsoring a brand new architecture podcast series, the first one which I participated in with Chris Haddad, Roger Sessions, Jeff Schlimmer and Dare Obasanjo. The subject is of the future of WS* and interoperability. Want to know what we all collectively think on the subject, check it out here:

http://www.microsoft.com/architecture/default.aspx?pid=share.podcast&abver=FEEB2E89-4412-4C58-A7F8-9B2CA0E0BDAC