Monday, August 18, 2008 @ 10:51 am,.Net,Matt Pavey
Coincidentally for the 3rd time in the past week an issue I was working on led me to an article written by
Scott Mitchell.
"The relay server information used by the SmtpClient class can be specified programmatically, through the SmtpClient class's properties, or can be centralized in Web.config. To use the Web.config approach, add a <system.net> element within the <configuration> element. Then, add a <mailSettings> element that contains an <smtp> element whose settings are specified within its <network> child element, like so:"
<configuration>
<!-- Add the email settings to the <system.net> element -->
<system.net>
<mailSettings>
<smtp>
<network
host="relayServerHostname"
port="portNumber"
userName="username"
password="password" />
</smtp>
</mailSettings>
</system.net>
<system.web>
...
</system.web>
</configuration>
Sunday, August 17, 2008 @ 6:20 pm,.Net,Matt Pavey
Here's another good article written by Scott Mitchell.
"When updating a web application that's currently in production, it is best to take the application offline so that users understand that the application is being worked on. This can be accomplished in a variety of ways, from simply stopping the web server software to displaying a web page that informs the user that the site is offline for maintenance. What you don't want to do is have the application appear to work, only to have some error pop up later because you are in the middle of updating the production server. This is a sure-fired way to frustrate your users."
The article discusses 4 ways to take an application offline:
- Taking a Website Offline through IIS
- Disabling the <httpRuntime>
- Using App_Offline.htm
- Creating a "Manage Offline Status" Page
Thursday, July 31, 2008 @ 6:49 pm,.Net,Matt Pavey
"The default ASP.NET settings ensure that forms authentication tickets are tamper proof and encrypted, and that ViewState is tamper proof. This ensures that any modification of the ViewState or authentication tickets either on the client's computer or over the network is detected when the server processes the data."
For example, when the viewstate generated on server A is posted back to server B you may receive a viewstate validation error if the <machineKey> is not the same on all of the servers in the web farm or cluster.
Here is one of the exceptions you may receive:
Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that <machineKey> configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.
This is because the viewstate is salted with a unique, autogenerated machine key from the originating server's machine.config file.
"This is done to prevent users from somehow tampering with the ViewState. Any change to the ViewState data on the client will be detected. But this has a side effect: it also prevents multiple servers from processing the same ViewState. One solution is to force every server in your farm to use the same key -- generate a hex encoded 64-bit or 128-bit <machineKey> and put that in each server's machine.config"
If you do not have access to the machine.config files in the web farm or cluster you can disable the enableViewStateMac using a simple page directive:
<%@ Page Language="vb" AutoEventWireup="false" Codebehind="MyPage.aspx.vb"
Inherits="MyAssembly.MyPage" enableViewStateMac="false" %>
Alternately, you can modify the pages element in Web.config:
<system.web>
<pages
enableViewStateMac="false" />
</system.web>
Of course caution should be taken when setting the enableViewStateMac to false since the viewstate could potentially be tampered with.
If you have a web farm or cluster and receive this error the optimal solution would be to update the machine.config files on all of the servers in the web farm or cluster to ensure that the <machineKey> configuration specifies the same validationKey and validation algorithm.
Tuesday, February 26, 2008 @ 4:42 pm,.Net,Matt Pavey
"Extension methods allow developers to add new methods to the public contract of an existing CLR type, without having to sub-class it or recompile the original type. Extension Methods help blend the flexibility of "duck typing" support popular within dynamic languages today with the performance and compile-time validation of strongly-typed languages."
Tuesday, February 5, 2008 @ 3:27 pm,.Net,Matt Pavey
<
asp:BoundField DataField="Email" HeaderText="Email" SortExpression="Email" HtmlEncode="False" ReadOnly="True" DataFormatString="<a href='mailto:{0}'>{0}</a>" />
Tuesday, January 22, 2008 @ 12:22 pm,.Net,Matt Pavey
Microsoft .NET Framework 3.5 contains many new features building incrementally upon .NET Framework 2.0 and 3.0, and includes .NET Framework 2.0 service pack 1 and .NET Framework 3.0 service pack 1.
.NET Framework 3.5 builds incrementally on the new features added in .NET Framework 3.0. For example, feature sets in Windows Workflow Foundation (WF), Windows Communication Foundation (WCF), Windows Presentation Foundation (WPF) and Windows CardSpace. In addition, .NET Framework 3.5 contains a number of new features in several technology areas which have been added as new assemblies to avoid breaking changes. They include the following:
- Deep integration of Language Integrated Query (LINQ) and data awareness. This new feature will let you write code written in LINQ-enabled languages to filter, enumerate, and create projections of several types of SQL data, collections, XML, and DataSets by using the same syntax.
- ASP.NET AJAX lets you create more efficient, more interactive, and highly-personalized Web experiences that work across all the most popular browsers.
- New Web protocol support for building WCF services including AJAX, JSON, REST, POX, RSS, ATOM, and several new WS-* standards.
- Full tooling support in Visual Studio 2008 for WF, WCF, and WPF, including the new workflow-enabled services technology.
- New classes in .NET Framework 3.5 base class library (BCL) that address many common customer requests.
Wednesday, September 12, 2007 @ 2:45 pm,.Net,Matt Pavey
Here's an interesting article by
Nigel Shaw about the fiercely contested debate regarding C# vs. VB.Net.
Let me say up front that I in no way agree with all of the comments or "opinions" made in the article, but I do think it's an interesting point of view. More than anything though I think he makes a great point regarding the fact that C# and VB are functionally equivalent!!!
Excerpt from Article:
We've seen that the cultures of VB and C# are very different. And we've seen that this is no fault of the programmers who use them. Rather this is a product of the combination of factors that collectively could be called their upbringing—business environment, target market, integrity and background of the original language developers, and a myriad other factors.
Excerpt from Article:
The brilliant insight Microsoft had was not to support multiple languages—if this was the case then surely it would not have bothered with J#, which is syntactically so close to C# that support for language’s sake alone would be ridiculous. The insight Microsoft had was to support multiple cultures.
One thing I found intersting in his article was his "In concrete terms" list regarding various statistics on C# vs VB programmers. Keeping in mind the numbers he uses are "opinions" and not actual statistics. But with that said, the one item I think is most important is:
A good programmer accomplishes two to ten times what an average programmer accomplishes, and causes 90% less bugs and headaches.
Regardless of language preference, I think the definition of a good programmer should be based on the quality of the code, performance, scalability, and long-term effectiveness of the code, not whether or not you chose VB or C#.
Examples of key differences between C# and VB are listed below. These are simply examples and not an exhaustive list:
- VB by default allows support for late binding. Although it can be turned off with
Option strict, the culture is such that it’s usually left on. This leads to numerous difficulty to catch errors. C# binding is always early.
- VB still supports the old
On error goto construct. This leads to sloppy or non-existent error handling. C# supports only the superior try…catch error handling.
- VB supports optional parameters. Although VB developers often list this as an advantage, it is a disadvantage because the use of optional parameters weakens the contract between the caller and the method, allowing the developer to slacken his analysis and get away with it until bugs creep in. [Note: C# param array construct is not the same as optional params]
- VB supports the legacy VB functions, with reference to Microsoft.VisualBasic.dll. Many of these functions are slow and they should all be avoided in favor of the .NET Framework. However many VB programmers still use them. In new VB projects, this dangerous namespace is included by default.
- VB allows implementation of interfaces with methods of different names, making it confusing and difficult to find the implementation. C# does not.
- VB supports background compilation. While this speeds the development cycle for small projects, it slows down the IDE in large projects, contributing at least in part to the culture tending to gravitate toward small projects.
- C# namespaces are managed in way that makes programmers aware of namespaces and their importance. VB namespaces are managed in a way that hides them from the programmers by default. Careful attention to namespace management is a fundamental tenet of strong application design and its importance cannot be overestimated.
The reason I'm posting a link to this article in the first place is because too many times when I'm researching a solution or looking at an article online I see someone post a code-snippet in VB or C# and there almost always is another post asking for the code to be converted to the other language. That of course always leads to a steamed argument about which language is better and why.
Taking the time to really understand the languages and the framework would solve most of these arguments and it would become very clear, in my opinion, that it's a matter of preference.
I come from a classic ASP and VB6 background, so naturally when .Net was evolving I made the quick transition to ASP.Net and VB.Net. I did very little to no C# programming for the first year or so. Not because I thought it was inferior, but because it was easier for me to continue down the VB.Net path and frankly most of the clients I was working with at the time had standardized on VB.Net, which made the decision even more obvious.
With that said, however, for the past few years I've became very involved with C# projects and I consider myself extremely fluent in both VB and C#.
I'm always learning new techniques each day, in both languages, so it makes it extremely rewarding to be able to be open-minded from project to project and make a seamless transition from one to the other at any given time.
My personal opinion is that if the client has standardized on a language, we as developers should honor that unless there is an obvious reason not to, and in certain circumstances I'm sure there are good reasons to make a recommendation.
I think the best thing is to be flexible and know as much as you can about both languages, as there are most certainly going to be times when you have to work on a project that isn't your language of choice.
Saturday, July 28, 2007 @ 11:16 pm,.Net,Matt Pavey
I am at the point where I am extremely comfortable developing solutions with Visual Studio 2005 and the .Net Framework 2.0... But Microsoft is about to release Visual Studio 2008 and the .Net Framework 3.5. It's pretty overwhelming at times trying to keep up with this industry, but then again, it's been a great industry to be involved in, so instead of complaining, I'll anxiously look forward to learning some new stuff. Apparently the new version is going to include JavaScript Intellisense and JavaScript debugging. I wouldn't say that I write a ton of JavaScript code, but it usually is always a pain to write and debug, so that's something I'll look forward to testing. Plus it's supposed to have some incredible AJAX support, among other things...
Wednesday, June 6, 2007 @ 11:08 pm,.Net,Matt Pavey
The patterns & practices team announced the official release of Enterprise Library 3.0 - April 2007 for the .NET Framework 2.0 and 3.0.
http://www.microsoft.com/downloads/details.aspx?familyid=62ef5f79-daf2-43af-9897-d926f03b9e60&displaylang=en
Good news, despite all the improvements in this release, there are no major changes so upgrading existing Enterprise Library 2.0 applications should be a matter of replacing the DLLs and updating the version numbers in the configuration files.
I've got a chance to use the Data Access Application Block in Enterprise Library 3.0 and just like advertised it was seamless to use based on previous experience with the 2.0 library and I've been very happy with how easy it's made my programming of late.
Keep up the good work!
