Tuesday, December 13, 2005
Sunday, November 06, 2005
The list goes like this:
Breaking Changes Overview
.NET Framework Version 2.0
- Threading Cancellation Functionality
- INullableValue Interface
- Boxing and Unboxing of Nullable
- MenuCommands Class
- Behavior Class
- ColumnWidthChangedEventArgs Class
- BindingContext Class
- DataGridViewRow Class
- DataGridViewCell Class
- Client Application User Settings
- Application Settings Serialization
- TreeView and TreeNode Classes
- BackgroundWorker Class
- MaskedTextBox Class
- GetPreferredSize Property of Form Controls
- Windows Forms API Changes
- CancelRowEdit Event
- AsyncCompletedEventArgs.Error Property
- RadioButton.TabStop Property
- MDI Automatic Merging
- BindingSource.Items Property
.NET Compact Framework
- EventArgs Classes
- XCertificateUI Class
- System.Threading.Thread Class
- KeyValuePair Class
- AssembliesVisibleTo Attribute
ClassVisual Studio Tools for Office
- VSTView Interface
Visual C++ Programming Language
- ATL Server — CAtlHttpClient Class
- Floating-point Control Word Support Functions
- Dynamic Cast from Private Base
- MFC Wrapper for LoadLibraryEx()
- MFC -bit Message Map Support
C# Programming Language
- Compilation Error Due to Implicit Conversion
- Checked and Unchecked Expressions
Does Not Satisfy IComparable Constraint Error
- Cannot Form a Delegate Over Nullable
- Operator "is" Returns true for T and Non-null T?
Visual Basic Programming Language
- TypeOf Statement
- Non-CLS Compliant Return Types
- Overriding Object Members in Structures
- Namespaces with Different Casing
- Implementing MustOverride Methods
- AppActivate Case-insensitivity
- AppActivate Right-Hand Title
- CreateObject Case-insensitivity
- Zero-Based Collection Object
- FileIO Enumerations
- FileLogTraceListener.CustomLocation Property
- FileLogTraceListener Date Format
ClickOnce Runtime Process
- ClickOnce Store Change
- WebBrowser Permissions
- Visual Studio Settings
- Machine.config File Changes
- Visual C++ Beta Project Open Error
- Errors When Deploying Device Projects to the Device Emulator
- Unique Class Names
- HTML Default Validation Schema
- Events for Non-Visible Controls
- ICallbackEventHandler.GetCallbackResult Method
- ASP.NET Personalization Database Schema
- Page.CreateStateFormatter Method
- Aspnet_regiis.exe Utility Argument Change
- WebPart File Format
- Relative References in the Configuration File
- Web Project Global Settings and Project Policy Settings
Saturday, November 05, 2005
Saturday, October 01, 2005
Friday, September 30, 2005
The Kid's Programming Language, or KPL, was developed under the direction of Jonah Stagner, and his colleagues, ex-Microsoft program manager Jon Schwartz and former NCR engineer Walt Morrison. The three run the software consultancy Morrison-Schwartz Inc.
"One of the things we realized is that we all learned programming on some flavor of BASIC when we started. You're not going to learn how to program in BASIC anymore," said Morrison, in an interview. "We wanted something that isn't 20 years old; modern technology that uses an integrated development environment, so we can take our kids and move them directly from this to the .NET environment."
KPL has its dedicated website and a descriptive article has been posted at MSDN's Code4Fun site.
Via: Yahoo News
Wednesday, September 28, 2005
Friday, September 23, 2005
Monday, July 18, 2005
Friday, July 01, 2005
The article starts with explaining what NULL actually is and puts forth four rules on NULL usage.
Rule #1: Use NULLs to indicate unknown/missing information only. Do not use NULLs in place of zeroes, zero-length strings or other "known" blank values. Update your NULLs with proper information as soon as possible.
Rule #2: In ANSI SQL, NULL is not equal to anything, even other NULLs! Comparisons with NULL always result in UNKNOWN.
Rule #3: Use SET ANSI_NULLS ON, and always use ANSI Standard SQL Syntax for NULLs. Straying from the standard can cause problems including portability issues, incompatibility with existing code and databases and returning incorrect results.
Rule #4: The ANSI Standard COALESCE() and CASE syntaxes are preferred over ISNULL() or other proprietary syntax.
Code owners previously using the InvariantCulture for string comparison, casing, and sorting should strongly consider using a new set of String overloads in Microsoft .NET 2.0. Specifically, data that is designed to be culture-agnostic and linguistically irrelevant should begin specifying overloads using either the StringComparison.Ordinal or StringComparison.OrdinalIgnoreCase members of the new StringComparison enumeration. These enforce a byte-by-byte comparison similar to strcmp that not only avoids bugs from linguistic interpretation of essentially symbolic strings, but provides better performance.
Recommendations for String Use
When developing with the 2.0 version of the .NET Framework, keeping a few very simple recommendations in mind will suffice to solve confusion about using strings.
- Use StringComparison.Ordinal or OrdinalIgnoreCase for comparisons as your safe default for culture-agnostic string matching.
- Use StringComparison.Ordinal and OrdinalIgnoreCase comparisons for increased speed.
- Use StringComparison.CurrentCulture-based string operations when displaying the output to the user.
- Switch current use of string operations based on the invariant culture to use the non-linguistic StringComparison.Ordinal or StringComparison.OrdinalIgnoreCase when the comparison is linguistically irrelevant (symbolic, for example).
- Use ToUpperInvariant rather than ToLowerInvariant when normalizing strings for comparison.
- Use overloads for string operations that don't explicitly or implicitly specify the string comparison mechanism.
- Use StringComparison.InvariantCulture-based string operations in most cases; one of the few exceptions would be persisting linguistically meaningful but culturally-agnostic data.
Sunday, June 26, 2005
- Base64 Encoding
- SOAP attachments
- DIME and WS-Attachments
In this method the attachment is included as binary data encoded in Base64 format inside a SOAP envelope. The XmlTextWriter class can be used to generate Base64 encoded attachments. The XmlTextReader class can be used to decode that binary stream back into the original data format. This mechanism is very resource intensive and the size of the encoded data is much higher than the actual data size. Say for example a 14KB binary file can become a 19KB text when encoded. Base 64 encoding has been around for some time and has probably received a bad rap for the opaque data problem. Base 64 encoding has some extremely nice benefits, such as its seamless integration in SOAP envelopes, it is a well-known standard, and it has better size efficiency than structured XML.
Interoperability: Excellent. Base-64-encoded data is understood on every platform that understands XML. Whether the opaque data included is in an interoperable form may be another question that is not already positively answered, like it is with the XML Representation approach. However, if you are sending opaque data and you are doing so with a Web service, then the interoperability issue has probably already been positively addressed.
Composability: Excellent. The fact that the data lives within the SOAP envelope means that all the WS-* specifications that Microsoft has developed with its partners will work seamlessly with a base-64-encoded XML element.
Efficiency: Modest. Although base-64-encoded data is usually more efficient from a message-size perspective than structured XML, as mentioned earlier, it still bloats the data by about 33% even when only single byte characters are used. The character set for base-64-encoded data does not require multi-byte characters, so if you can use UTF-8 encoding you can avoid the extra 100% increase in size. Of course you cannot mix single and multi-byte encodings within a single XML message, so if the rest of your SOAP envelope requires multi-byte encoding, then you have to live with the two-fold increase.
When to use: Base 64 encoding is probably the best way to pass opaque data if transport size efficiency is not your first concern. It will work seamlessly with higher-level WS-* protocols and is smaller than a standard XML encoding.
This is a much familiar method of binding a SOAP message with MIME enabling the usage of MIME encapsulation. In this mechanism there is a primary SOAP message and one or more attachments. SOAP with Attachments was the first attempt by Microsoft (along with Hewlett Packard) at solving the opaque data/attachments problem.
Interoperability: Potentially decent in the future with some notable exceptions. SOAP with Attachments is simply a W3C Note; it is not a W3C Recommendation or even a W3C Working Draft. Presumably, after the profile is final and conforming implementations are available, they should be interoperable. The problem is that when it comes to the attachments profile, WS-I is ignoring the fact that SwA breaks the Web services model. Among other issues, SwA specifically does not work with WS-Security at this time.
Composability: Poor. Without an encompassing SOAP envelope to build upon, SOAP with Attachment messages do not compose well with the WS-* specifications. In particular, a non-SOAP-message-based transport cannot support the recently finalized OASIS WS-Security specification.
Efficiency: Good. Although not as efficient and streamlined as the DIME and WS-Attachments approach, opaque data can be sent in its raw form without base 64 encoding. There are issues with buffering incoming data due to the lack of a length header on the message sections, but it is a viable solution to the problems around sending potentially large, opaque blocks of data.
When to use: If you have interoperable SOAP with Attachments implementations on all the platforms that you might want your Web service to be accessible from, then you might consider using SwA. If you find you are really only communicating between computers running the same platform, then the reason for using Web services (interoperability) is moot, and you might as well use a proprietary communication mechanism. Finally, you will specifically want to avoid SwA if you need OASIS-compliant WS-Security type signatures or encryption on your opaque data.
DIME and WS-attachments:
Direct Internet Message Encapsulation (DIME) is a lightweight, binary message format that can be used to encapsulate one or more application-defined payloads of arbitrary type and size into a single message construct. Each payload is described by a type, a length, and an optional identifier. Both URIs and MIME media type constructs are supported as type identifiers. DIME and WS-Attachments is a faster and more efficient solution to the attachments approach to opaque data compared to SOAP with Attachments, but has the same composability problems as SwA.
Interoperability: Modest. Although DIME is a simpler protocol than MIME that would bode well for its interoperable possibilities, efforts for creating widely interoperable DIME and WS-Attachment implementations have stopped. As with SwA, there is no recommendation for DIME or WS-Attachments at this time. Microsoft tools currently only support a DIME approach to attachments.
Composability: Poor. As is the case with SwA, a non-SOAP envelope approach to messaging like DIME and WS-Attachments limits the ability of the higher-level Web service specifications to properly work upon a message.
Efficiency: Very Good. DIME is a simple binary format for transmitting raw data and has support for such efficiencies as chunking and jumping easily between message records.
When to use: Web services are all about interoperability, and if DIME and WS-Attachments does not provide wide interoperability, then there is little reason to use it. If you are not interested in interoperability but believe DIME is attractive for its performance reasons, then you would probably be better off using other proprietary, high-performance solutions such as .NET Framework Enterprise Services. DIME and WS-Attachments also suffer from the same limitations as SOAP with Attachments, in that it is only viable if you do not require higher-level capabilities for your Web services. At this point the only real reason to be using DIME and WS-Attachments would be to interoperate with an existing DIME and WS-Attachment implementation.
Tuesday, May 24, 2005
Yesterday I tried to install Beta2, but the directions said I have to remove my previous 2.0 Beta1 installation. I was not sure... so postponed the installation to this weekend...
Wednesday, May 18, 2005
Via: The ServerSide .NET
Sunday, April 10, 2005
Wednesday, April 06, 2005
Wednesday, February 23, 2005
Monday, February 21, 2005
With WS-Security, getting down to the business of providing interfaces and programming toolkits that all "speak the same language" has become easier and developers can begin to use the benefits of these efforts. A SOAP message, on its own, can be authenticated, its integrity verified, and it can be encrypted in whole or in part using the mechanisms defined in WS-Security. The architectural model of WSE is built on a "pipeline" of filters that process inbound and outbound SOAP messages. This is built on the pre-existing SOAPExtension classes, and developers who have experimented with SOAP Extensions for compression, encryption, logging and other purposes will find the implementation familiar.
WS-Security and the WS-Security addendum are published at http://msdn.microsoft.com/ws/2002/04/security and http://msdn.microsoft.com/ws/2002/07/Security respectively. Since the release of WS-Security it is emerging as the primary industry standard for secure Web service communication. This spcification fully leverages the existing XML signature and XML encryption protocols and optimizes them for use in SOAP message-based Web services environment to support the transmission of security tokens as well as encryo\ption and digital signatures. WS-Security describes the folowing SOAP header elements:
- Security - the root WS-Security element in the SOAP header
- UsenameToken - A child element that supports simple username and password authentication mechanisms
- BinarySecurityToken - A child element that supports binary-based security tokens such as Kerberos tickets and X.509 certificates
- SecurityTokenReference - A child element that supports referencing remote security tokens that are available at a URI
- KeyInfo - A chil element that supports inclusion of key information (derived from XML signature)
- Signature - A child element that supports signing one or more parts of a SOAP message (based on XML signature)
- ReferenceList - A child element that supports referencing one or more encrypted elements in the body of a SOAP message (based on XML encryption)
- EncryptedKey - An element that supports encryptionspecifically for keys (based on XML encryption)
- EncryptedData - A child element that supports including additional encrypted data in a SOAP header (based on XML encryption)
- Timestamp - The WS-Security Addendum specification that supports including timestamp info in the SOAP header that can be used to prevent replay attackes when an attacker tries to reuse an ols message.
Tuesday, February 15, 2005
For more read HOMOGRAPH ATTACKS.
Monday, February 07, 2005
What is WSE?
The Web Services Enhancements aka WSE is a .NET class library that augments the .NET Framework and related technologies to provide an implementation of various WS-* specifications including WS-Security, WS-SecureConversation, WS-Trust, WS-Policy, WS-SecurityPolicy, WS-Addressing, and WS-Attachments. WSE allows you to add these capabilities at design time using code or at deployment time through the use of a policy file.
What are the specifications covered by WSE?
We shall look into each one of them in future posts.
Wednesday, February 02, 2005
Tuesday, January 11, 2005
Update: Now they require Tech. Leads, Project Leads and developers too. .NET/SQL2000/Oracle/C# or VB.NET. Need to have good ASP.NET skills.