Just to let those who attended my talks in Amsterdam this week at SDC, I will be posting the links and samples for each talk by the end of this weekend...right now I'm getting ready to leave town for Tech Ed in Orlando...but I have not forgotten you!

With all of the new product launches forthcoming...things are starting to get muddy...and I found this excellent post from Rob Caron that at least makes a good start for understanding the tiers and relationships between the Express, Visual Studio and Visual Studio Team System products. These are a must read:

http://blogs.msdn.com/robcaron/archive/2005/04/15/408426.aspx

http://blogs.msdn.com/robcaron/archive/2005/04/20/410207.aspx

But, be prepared that there are still many unanswered questions regarding pricing for VSTS and how it fits with existing partner programs and MSDN subscriptions. Microsoft is still working on this story, based on feedback from the business community, so you should stay tuned for more information from Microsoft in the June/July timeframe to provide clarity.

My latest globalization article is now live on The Server Side .NET, and I'm working on some new code samples for 2.0, for my upcoming talks at Tech Ed, so stay tuned for more updates on my globalization resource pages!

http://www.theserverside.net/articles/showarticle.tss?id=LocalizationPractices

I recently received this question at SearchWebService.com...

How can I call a Web page from my Web service page after extracting an XML file into a dataset? My Web page will display data from a created dataset into a DataGrid control. Can I return data directly into a Web service page using Visual Studio .NET?

Probably because I have had to go through some interesting integration patterns in the past, I answered the question with two flavors...discussions welcome.

Here's my answer:

I think the best way to tackle your question is to review the workflow between client, Web service and Web application (pages). If the client application is the Web application, then the workflow looks something like this:

1. User browses to a page.

2. During the Page.Load event you invoke a Web service to get the dataset, before binding that dataset response to a DataGrid control on the Web page.

3. The page is returned to the browser with the populated DataGrid rendered as HTML.

The call chain looks like this:

Browser->Web Page->Web Service

What may be misleading about your question is the statement “call a Web page from my Web service”. Web services are data centric calls. They do not return HTML that can be displayed in a browser, therefore they should not be responsible for “calling” a Web page. Rather, the Web page should call the Web service to gather data, and present it. The driver behind the activity is the user who navigates to a page that leverages the service.

That said there is another possibility that can be interesting. Consider this workflow:

1. User interacts with a Windows client application.
2. The application at some point invokes a Web service to gather data from a remote server. The Web service establishes a session for the caller, and allocates the dataset to the session. The Web service returns XML that includes a link to a Web page exposed by the same server.
3. The client application retrieves the XML response, which includes a URL to a Web page to navigate to (with session established) and the client application launches a browser (or, has an embedded custom browser) to the URL.
4. The requested URL (page) retrieves the dataset from the session object, and displays the page fully populated.

So, the call chain is now:

Windows App->Web Service

Windows App -> Browser -> Web Page

This type of workflow may seem disconnected, however it is one technique whereby a legacy application can integrate with a modern user interface (through the browser) when the legacy app wants to integrate the modern application’s services as part of a user interface workflow, in addition to data exchange. For example, the insurance industry has many legacy agency management system applications, some even DOS-based entry screens, that “work” therefore will not be replaced. These agency management systems hold important data necessary to create certificates of insurance, a service often provided by external, modern applications. These modern vendor applications rely on data from the agency management system to function, therefore a data exchange must be automated as part of the workflow, enabling the modern application interface to pick up where the legacy system left off, and finish the job.

What a great turnout for the .NET conference in Long Beach last Saturday! I was amazed at how many faced I recognized from San Diego, Orange County and LA!!!

Anyhow, my slide deck for the presentation is here as promised:smartclient_ocevent1.zip (412.28 KB)

I'll update this blog post tonight with the code sample. Just cleaning up some things that I had converted for Beta 2. Stay tuned!

Updated 05/09/05 - code sample from demo:ClickOnceDemos.zip (368.13 KB)

Ok, I noticed a few other little things about the publishing process through Visual Studio 2005, related to Beta 2. So, in an effort to save you all the 45 minutes I wasted on some of these things, here's the list. Luckily, I was somewhat aprised of this before I did my presentation yesterday, however, it still ate up some demo time given that things didn't always work the first time...

1. Publishing will continue even if you can't successfully build (see my previous post), so I recommend you always try to build first and watch your output. I know what you are thinking: “Oh, I'll just publish and check the output window for errors before I run the app”. But, I guarantee you will be sometimes seduced by that little browser window with the “Install” button...and you'll forget...and you'll find a bug...and you'll try to think about what the problem is but really you didn't get the latest assembly (or, worse, the assembly you're referencing never was built).

2. The “Properties” tab doesn't appear to be saved as part of the build step. So, if you make changes they won't be reflected when you publish...another ghost. The problem is, it still increments the published version, so you “think“ you have it.

3. Sometimes, not always, if you don't version your assemblies, the updated code is not deployed with the newly published version. This problem seems strange to me, since the published application version has been incremented...however I haven't had time yet to inspect what the cause of this is, in terms of the server deployment and its files.

If I see any more problems, or find a solution for these issues...I'll update this post. Feel free to comment if you find it before I do, I'm about to bury myself in ASP.NET 2.0 and Indigo for the next few weeks, I won't have much time for ClickOnce...

Having some trouble getting ClickOnce publishing to work on Beta 2? Yeah, me too. On several of my VPCs and on a recent client's laptop machine, the Beta 2 install appeared to share the same problem. When publishing a smart client application through the Visual Studio IDE, the following error appeared:

Publishing files...

'C:\SmartClientDemos\ClientApp\ClientApp\publish\setup.exe' to 'http://localhost/ClientApp/setup.exe'. Unable to add 'setup.exe' to the Web. Unable to add file 'setup.exe'. The system cannot find the file specified.

Ok, so I just had a long discussion with one of the smartest guys I know, my colleague, mentor and friend - Juval. We were talking about strong names, full trust the global assembly cache and .NET assemblies. It started out innocently enough, however as the discussion continued, we both insisted on being right...and as it turns out, we were both right...but I still lost $1 due to my own muddy description of the bet. Perhaps you've been confused by this as well? Read on...

She said:

When you deploy assemblies to the GAC, they get full trust.

He said:

No, you're wrong. The GAC has nothing to do with the assignment of privileges. You want to bet? I can prove it.

She said:

No, I'm sure of this, I do it all the time with my ASP.NET applications when I deploy business objects to the GAC. They get full trust. This is important because it is the only way I can reduce the privileges of the ASP.NET application assemblies (using the <trust> element as I discuss in my article here: http://www.theserverside.net/articles/showarticle.tss?id=SandboxingComponents), and then elevate privileges as needed to invoke assemblies that demand full trust or other permissions. The stack walk would fail, if I were not able to elevate privileges at some point, and assert to circumvent the stalk walk. I certainly don't want ASP.NET application assembly to run with full trust if I can avoid it.

He said:

Ha, I'm right. You see?

So, he demos his client app (EXE), with a dependency on another assembly (DLL) that was deployed to the GAC. He removed full trust for assemblies deployed to local machine. Then he invoked a .NET assembly that required full trust. Sure enough, the permission demand fails.

She said:

Crap. Thinking thinking thinking...Well, wait a minute, you need the policy to at least grant full trust based on the strong name or something like that? Darn it, what is it? I know there is something...ok I didn't describe this right...(fumbling)...I mean...er...I wasn't trying to say GAC = full trust, but that you need to deploy to the GAC, at least with ASP.NET...to get full trust...hmmm...ok, here's your damn dollar.

ABOUT AN HOUR LATER

She said:

Aha! I went and reread my article (above) and it jogged my memory...basically, ASP.NET runtime uses different security policies to assign permissions. Inside the security policies for ASP.NET such as web_lowtrust.config, web_hightrust.config, etc...there is a setting that pulls in full trust for GAC assemblies, automatically.

                 <CodeGroup

                                class="UnionCodeGroup"

                                version="1"

                                PermissionSetName="FullTrust">

                            <IMembershipCondition

                                    class="UrlMembershipCondition"

                                    Url="$Gac$/*"

                                    version="1"

                            />

If only I could remember these things in the heat of discussion, I would be $1 richer right now.

Ok, you were right...but so was I :) Ego somewhat repaired.

No, please, make it stop, don't make me go back, I don't want to go back...I'll never go back...ok, fine, I'll go back...for now...but I won't like it...

Well, if you haven't stated these words, or thought them, or something like them, you will...believe me. Once you get your hands on ASP.NET Beta 2, it is next to impossible to look at 1.1 again without holding back tears of pain. It's like buying a killer new outfit...you want to wear it right away, not hang it in the closet for later! Yeah, you know what I mean.

Unfortunately, there are plenty of companies out there that are not ready to embrace Beta 2 as their current development platform for new applications. Nor are they prepared to migrate all 1.1 applications just because 2.0 is cool. It's called a business decision...companies don't make money by converting code to new platforms just because. Migration and platform upgrades require planning.

So, the question is, how can ASP.NET developers lessen the pain of returning to 1.1, and better prepare to migrate their code to 2.0? Well I just happen to be updating one of my migration speeches these next few weeks, in preparation for the SDC conference I present at each May in The Netherlands. So, I'll be posting some blogs on the subject, based on the following core topics:

• Master Pages
• Navigation Controls
• Data Controls and Binding
• Security Controls and Membership API
• Configuration
• Caching
• Localization
• Personalization
• Deployment

Have any other hot points to add to the list? Let me know! Otherwise, watch for the migration blogs forthcoming...