Although many are using the new OnClientClick property to ask “are you sure?” before letting users delete records, I have discovered that it can completely change (for the better, for the way better) how I have been constructing code for handling ink on the web. [read more …]
[A DevLife post]
We’ve been off the tour for a while. If you live in the area, be sure to attend this!
Remember that if the attendance is poor, these will go away again.
Tuesday Sept 26th 1pm – 5pm Wyndham Hotel, Downtown Burlington
Featuring our own MSDN DCC: Susan Wisowaty!
Get Connected with the .NET Framework 2.0 and Visual Studio® 2005 (and Beyond)
These days, it seems like everything’s talking. Smart Client applications are sending emails and uploading and downloading files from the Internet. Browsers are talking to Web servers asynchronously. And enterprise systems are using a myriad of Web Services, .NET Remoting, and other technologies to get the job done.
Fortunately, it’s easy to keep the conversations flowing with the Microsoft .NET Framework 2.0, Visual Studio 2005 and the forthcoming WinFX® platform. In this free half-day event, you’ll see the future of writing connected systems by exploring the upcoming Windows Communication Foundation. Check out how easy it is to send mail, work with FTP and HTTP, and detect network availability and status by using the System.Net namespace. And learn how quickly you can create AJAX-style applications by using the powerful new “Atlas” framework.
Session 1: Exploring the System.Net Namespace in the .NET Framework 2.0
Session 2: Windows Communication Foundation Exposed
Session 3: Building the Next Generation of Web Applications with ASP.NET “Atlas”
I learned this the hard way, as usual.
We had to change the X509 Certificate that we were using for our application. That meant that the policy config file on the client and the app had to have the certificate identity defined by the findValue parameter of the X509 node.
<
serviceToken>I made all of the necessary changes and ran the client app. I received an error from the server:
“WSE2006: EncryptedKeyToken in the security header of the incoming message is encrypted with a different security token than expected.”
That’s telling me that the certificate on the client side doesn’t match the certificate on the server side. After triple checking my setup and configuration, I went to turn tracing on on the server side to see what the heck was going on. This meant modifying the web.config. Suddenly the app worked.
Editing web.config forces an app restart so this made me realize that the policy file must have been getting cached in the AppDomain and the restart forced the revised policy to be read. Mark Fussell confirmed that to be the case.