You must also take into consideration the following use-cases that your web part will participate in:

• From the site’s Web Part Gallery, clicking the web part and rendering it in “Preview mode”.
• When editing the page that has the web part in SharePoint Designer 2010, that the web part renders properly as a user-control.

I want to focus on properly rendering the Web part in SharePoint Designer because this is a use-case that can be commonly missed. Today, I was testing a web part I am developing for Zenpo Software Innovations when I encountered the following error in SharePoint Designer 2010:

“Error Creating Control” – what does that mean?

The web part’s OnLoad and OnInit event-handlers didn’t check that the page is in “design mode”. So, it tried to render its content as if it was in browse-mode.

The web part uses custom JavaScript. I have to register the scripts in order for the web part to use them. I implement the script-registration during the OnInit event of the web part like the following:

        protected override void OnInit(EventArgs e)
        {
                if (!Page.ClientScript.IsClientScriptIncludeRegistered("Script1"))
                {
                     scriptRegistered = false;
                     Page.ClientScript.RegisterClientScriptInclude("Script1",
                            Page.ClientScript.GetWebResourceUrl(this.GetType(),
                            "Zenposoft.Script1.js"));
                }
        }

This script registration code works fine on the web browser. The problem is when this code is invoked during SPD-editing of the web part page, Page.ClientScript.GetWebResourceUrl returns empty string (under normal browsing state, it would have returned the URL to the WebResource.axd file). And you cannot pass an empty string URL to the Page.ClientScript.RegisterClientScriptInclude method (it will throw an exception if you pass an empty URL). The web part really had no business trying to register scripts during design-time.

You might say to yourself, “this shouldn’t be an issue since Web part pages are edited through the browser anyway”. Think again! Web designers at your organization will use SharePoint Designer at some point to edit SharePoint pages and if your web part cannot handle “design mode” correctly, the designers will see the ugly “Error Creating Control” in SPD. You cannot instill confidence in the use of your web part if it’s throwing exceptions in SharePoint Designer!!!

So, how do we fix this? You can use the one of the following or both:

• SPContext.Current.IsDesignTime
• Control.DesignMode

I found this Microsoft SharePoint Designer Team Blog post that has nice explanation on how to create “designer friendly controls”. SPContext.Current.IsDesignTime and Control.DesignMode are mentioned in that blog post.

First, I modify the OnInit event-handler such that I register scripts only when “not in design mode”:

        protected override void OnInit(EventArgs e)
        {
            if (!this.DesignMode && !SPContext.Current.IsDesignTime)
            {
                if (!Page.ClientScript.IsClientScriptIncludeRegistered("Script1"))
                {
                    scriptRegistered = false;
                    Page.ClientScript.RegisterClientScriptInclude("Script1",
                            Page.ClientScript.GetWebResourceUrl(this.GetType(),
                            "Zenposoft.Script1.js"));
                }
            }
        }

After deploying the modified Web part, we check SharePoint Designer and the errors are gone:

SharePoint Designer Errors - Gone

Yes, the errors are gone but we need to display something where the web part(s) are embedded. If the web part in on the page, the designer should render something there; it can’t be just white-space.

In order to render something in “design mode”, we override the Render method of the web part:

        protected override void Render(HtmlTextWriter writer)
        {
            if (this.DesignMode || SPContext.Current.IsDesignTime)
            {
                writer.Write("<input type="button" value="Web part is in edit mode..." />");
            }
            else
            {
                base.Render(writer);
            }
        }

If the web part is in “design mode”, we render a simple HTML button. Otherwise, we let the base class (WebPart) handle the rendering. Deploy the updated web part and you should now see the following in SharePoint Designer:

Render HTML button in Desing Mode

To summarize, you will want to render web parts correctly in designers such as SPD 2010.  The likelihood that Web designers will edit SharePoint pages in SPD is high enough that you will want to “design mode” for your web part to run properly.

http://www.microsoft.com/technet/security/bulletin/MS10-070.mspx

Now, if the detection tool reports that your apps are vulnerable, and the apps are public-facing (on the Web), you will really want to consider the workaround.

The emphasis of the workaround is to “homogenize the error codes”. The exploit relies on error codes returned by the application to an attacker. The more differentiated the error codes, the more it learns about the encryption, and the better chance it has on cracking the encryption (read-up on “Padding Oracle Attack”).

I created a stripped-down test ASP.NET Web application project that initially has customErrors=”Off”. Within the project, I created pages that will deliberately throw errors. I have a “Divide by Zero” page, a “Throw Error” page, a “View State Exception” page, and a link from the default page to a non-existent page. I used Fiddler to monitor the traffic to and from the app while customErrors=”Off”. Next, I apply Scott Guthrie’s ASP.NET workaround for this vulnerability. I set customErrors=”On” and initially, I use redirectMode=”ResponseRedirect”. The HTTP 500 response codes disappeared but there are still HTTP 302 (redirect) responses. See the evolution of the response codes as I changed the customErrors section:

customErrors=”On” starts at line 13 in the screenshot above. No more HTTP 500 once customErrors was turned on. However, there are still HTTP 302, which may clue-in the attacker that an error occurred and hence the redirect to a generic page.

So we change the customErrors element once more time. I set redirectMode=”ResponseRewrite”:

   

<customErrors mode="On" defaultRedirect="fatwhale.htm" redirectMode="ResponseRewrite" />

(By the way, in case you’re wondering what the “fatwhale.htm” page is, it is in reference to the twitter whale whenever twitter service gets overloaded.)

After setting redirectMode=”ResponseRewrite”, the traffic captured by Fiddler shows that everything is consistently HTTP 200, even though we know that run-time errors were occurring on the individual pages:

Scott responded to some of the comments in his blog post and he strongly encouraged people to homogenize the response/error codes. The Fiddler screenshots I showed above is what I think Scott Gu means by “homogenizing the codes”.

At this time we are not aware of any attacks using this vulnerability and we encourage customers to review the advisory for mitigations and workarounds.

Oh yeah, add the fact that the article starts with:

Today we released Security Advisory 2416728 describing a publicly disclosed vulnerability in ASP.NET that affects all versions of the .NET Framework.

If those lines don’t get your attention, I don’t know what will!

A detection script was made available also at the TechNet article “Understanding the ASP.NET Vulnerability”. The script is ran as a VBScript and will report all Web app configurations that are vulnerable. If your apps are not vulnerable, the script will report “OK” on the app. The report looks like the following:

Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

Enumerating possible paths with ASP.Net configuration that have custom errors turned off.

C:\inetpub\wwwroot\web.config: ** Vulnerable configuration found **
C:\Inetpub\wwwroot\TestApp1\web.config: ** Vulnerable configuration found **
C:\Inetpub\wwwroot\wss\VirtualDirectories\2639\wpresources\web.config: ** Vulnerable configuration found **
C:\Inetpub\wwwroot\wss\VirtualDirectories\4444\web.config: ** Vulnerable configuration found **
C:\Inetpub\wwwroot\TestApp2\web.config: ok

If your app shows “Vulnerable configuration found”, then the Security Advisory is applicable for that app. You want to see “ok” like in the last line of the example above.

The vulnerability is called “Padding Oracle Exploit”. The attacker will attempt to send tampered data to the web server and the web server will generate error messages. As more error codes get returned to the attacker for the tampered requests, the attacker can learn what the encryption is. Once the encryption is compromised, the exploit beings. This vulnerability will allow an attacker to read data, even encrypted ones such as data stored in the View State, and even download files such as the web.config file from the target server. (But requests for web.config files cannot be served by IIS, right???) Scott Guthrie explains in his blog how this vulnerability works. Scott also explains how to workaround this issue. Before a patch or security update appears, this is the best tool against the exploit provided by Microsoft.

You say “But I never store sensitive information in the View State!” Well, read on. In the Microsoft TechNet Security Advisory (and even Scott’s blog post), the workaround’s main theme is homogenizing the error page. The TechNet security advisory says “Homogenizing errors is a crucial component to help protect against this attack.” This means turning customErrors to “On” and explicitly specifying the defaultRedirect page. For full details, please read Scott Guthrie’s blog post.

Now, you might say, this is just another over-hyped, exaggerated propaganda by the Microsoft haters. Well you can throw that argument out the window since it is Microsoft itself that is telling its customers about the vulnerability. There is also a Common Vulnerabilities and Exposure entry for this. The CVE entry says it just has a “candidate” status on it right now and may even be “rejected in the future”.  Is that grounds for ignoring it because it’s just a “candidate” CVE entry? Is it really worth ignoring because the probability and severity of the exploit has not been fully established yet? For public-facing sites, I recommend you implement the workaround as soon as possible. The workaround is fairly cheap to implement—just do it! There will be many apps that will be fine and no workarounds would be necessary (their customErrors configuration is already protected against this exploit). But if the detection tool above says “vulnerable” on your site, and the site is public facing, all I can say is “Wow!” should you decide to ignore it.

It’s so easy to do a “Hello World” Web part project now. These days, my Hello World projects typically involve opening up a database table and displaying records in a table. I was able to do this with minimal coding and got it up and running—a full blown Web part—in under 15 minutes!

I created a sample project that opens up the AdventureWorks database and displays employee records in a table:

Sample Visual Web Part Project using Adventure Works Database

The Web-part looks like the following when used inside SharePoint:

AdventureWorks Employees Web Part So far, I like it!Here are my first impressions:SharePoint project templates come out-of-the-box install of VS 2010. After installing VS 2010, the SharePoint project templates are ready for use. No need to do installations of VS-extensions.SharePoint Project Templates in Visual Studio 2010

• The Visual Web Part project cannot be deployed as a “sandboxed solution”. It has to be deployed as a farm solution.
• Project-debugging became a lot easier even with a full-blow farm-deployment. Press F5 in the VS 2010 IDE and Visual Studio will build, package, deploy, and activate your feature, and launch the debug-browser all in one click! When you’re done debugging, terminate Internet Explorer, Visual Studio will deactivate and retract the solution out of SharePoint.
• IIS-reset (for the target Web app) even for full-blown deployments when debugging is fast!
• Remember in VSeWSS 1.3 where you had to Google first how to specify the group the Web part appears in because it wasn’t so obvious? Well, it got easier in VS 2010! Now, the Elements.xml file has a place-holder for the Web-part group. All you have to do, is change it from “Custom” to whatever value you want it to be. It’s so visible now you can’t miss it.

Web-Part Group Place-Holder in Elements.xml File

• You can now add Web User Controls (ASCX files) into the project! As a matter of fact, the project template adds one ASCX file for you. This just made Web Part development a HECK of a lot easier! This is HUGE! Back in VS 2008 developing SharePoint 2007 Web parts, there were no designers available. If developers wanted to use ASCX files, they had to create regular ASP.NET Web apps, design the ASCX files there, write the code-behind, compile the project so the code-behind logic gets packaged with the ASCX files, deploy the ASCX files to UserControls folder within the SharePoint virtual Web app folder, deploy and enable Smart Part, add a Smart Part Web part to the SharePoint pages, then finally, hook-up the Smart Part to the ASCX files. Whew!!! Talk about LOTS of steps! In VS 2010, you don’t need Smart Part or that lengthy way to integrate ASCX file in SharePoint anymore. The challenge of “imagining” what your Web part will look like as you write your C# code is no more. The designer is built in to the Visual Web Part project. Leverage your ASP.NET skills to the max.
• Despite all the improvements, Web part development veterans should recognize familiar concepts and project files such as Elements.xml, .webpart file, strong-named key file, packages and features. 

I have many ASP.NET developer friends who didn’t want to get into SharePoint development because:

• The Web part project wasn’t easy in SharePoint 2007. No designers, hard to design a visual element.
• ASP.NET developers got accustomed to easy debugging of their projects by simply pressing F5 key or the play button on the IDE toolbar. In 2007, ASP.NET developers thought deploying the app and then attaching to the w3wp.exe process (multiple manual steps, not one) was too cumbersome.
• It took forever to even debug the code because the SharePoint Web app always recycled on deployments.

If you are an ASP.NET developer contemplating if you should try SharePoint development, I highly recommend you try it NOW! SharePoint 2010 development feels like traditional ASP.NET development more than ever!

I purchased a Macbook Pro a week ago and started coding an app within the first 2 hours of getting home! I tell you what, I’ve been a PC for a long, long time and a first-time Mac owner. This Macbook Pro Unibody plus the Snow Leopard OS is a really one sweet device. Am I done with PC laptops? Nope–I’m just waiting for the HP Envy 14 series to come out–16Gb RAM config with newest iCore 7 chip plus SSD drives–that’s going to be my configuration for SharePoint 2010 mobile development. Anyway, back to the Macbook. So, I started coding my first night owning the Mac. I saw some samples on the Web and started coding iPhone apps. Holy-moly! I saw and typed keywords that I haven’t used since college (I think)–the malloc and dealloc commands/keywords!!! I dreaded those things as a young programmer. Memory leaks, buffer overruns–yep, I got burned many times when I was starting out and I didn’t allocate/deallocate memory properly in my programs.

So, what does iPhone development got to do with .NET development? Well, technology-wise, they are different worlds. XCode uses Objective-C while .NET (mostly) uses C#. They’re kind of like distant cousins; they’re similar in some ways but different in many ways. No, I’m not recommending you abandon .NET and totally convert to XCode. I’m recommending that you try iPhone development because it will bring you back to fundamentally sound programming practices. As a developer, I felt like it brought me back to my roots.  Developers need to be mindful of performance and memory use when developing for the iPhone.  In XCode and .NET, there are garbage collectors. Developers don’t worry about memory-allocation thanks to the garbage-collectors. iPhone apps don’t have garbage-collectors. Also, device memory is limited on the iPhone. No gigs of RAM. No swap files. Should you try iPhone development, you will see malloc and dealloc again and you will be constantly asking yourself “maybe I should clean-up stuff in memory and make room for new objects”. If you’ve never seen malloc and dealloc, we’ll I hope it’s a fun experience discovering for the first time what it’s like to develop where you are constrained by limited memory. 

.NET developer with a Mac: go try iPhone development. If anything, because you’re forced to think limited CPU cycles and limited memory, it should improve your overall programming skills!

Sequence property of the WebConfigModification can be used to figure out the uninstall order.

Unnamed sections such as connectionStrings and bindings sections, appear to have an XPATH expression that may result in duplicate matching. But, the ApplyWebConfigModifications method of the WebConfigModifications object will do it correctly as long as:

• EnsureChildNode is used as the type
• Add/Remove in order that is logical. Example: add connectionStrings section first then the add elements inside the connectionString section.
• If you are worried that de-activating a feature will obliterate the connectionStrings section because your feature created it, don’t. SharePoint will only take out the connectionStrings if there are no other entries created by the ApplyWebConfigModifications inside the connectionStrings section. If other features inserted 1 or more connection-string entries there, your feature-receiver will not remove the connectionStrings section. Now, if the connectionString section got edited manually, the SharePoint WebConfigModifcations object will not know this and it doesn’t matter how many child-nodes there are inside the  connectionString object. The root element (connectionString) in this case will be removed because in SharePoint’s perspective, there are no existing Web-config modifications inside connectionString.

Conclusion: if you are going to adopt feature-receivers to install web.config entries such as connection-strings and bindings (for Service-References), you must also adopt to policy to discourage manual insert/modification of the web.config entries. Be consistent.

There are still some Coldfusion developers in this organization but these Coldfusion apps are being phased out and eventually  will be converted to ASP.NET and/or SharePoint. These Coldfusion developers do not have a background on ASP.NET programming model, which is really different, closer to VB6 model if you look at it that it is closer to “classic ASP” model. “Classic ASP”, Coldfusion, and PHP are in the same category in my book—they are server-side scripting. ASP.NET and  SharePoint on the other hand are more object-oriented.

One of the Coldfusion developers asked me which topics on ASP.NET and SharePoint should they learn and in what order. They are excited to develop SharePoint stuff such as Web parts and workflows but need some guidance on where to start.

Here’s the list of high-level skills/topics I pointed out one should in order to develop SharePoint solutions:

• ASP.NET model
  • ASP.NET User Controls
  • Intrinsic Objects (HttpContext, Application, Request, Response, Server, etc.)
  • ASP.NET Page life-cycle
  • C#
  • ASP.NET Web App configuration files
  • .NET Namespaces
• Object-Oriented/Component Programming
  • Properties and Methods
  • Events
  • Delegates
  • Inheritance
  • Implementation (interfaces and abstracts)
• SharePoint Features Development
  • Visual Studio SharePoint Project Extensions/Templates
  • SharePoint Object Model
  • Deploying Features using STSADM

Most objects in ASP.NET Framework are allocated/deallocated in memory automatically. However, there are objects that inherit from the IDisposable. You have to explicitly dispose objects that implement the IDisposable interface or you will run the risk of memory leaks. Some examples of ASP.NET objects that implement IDisposable include Connection, Command, Adapater, and Reader objects (in the System.Data namespace). You can perform any of the following to dispose these objects properly:

SQLConnection connection = new SQLConnection(connectionString);

//use the connection object here

connection.Dispose();

Or, you can using the using statement:

using(SQLConnection connection = new SQLConnection(connectionString))

{

                //use connection object here

} // don't have to call Dispose(); the using statement will dispose connection correctly

When working with SharePoint API (SharePoint .NET libraries and not the SharePoint Web services), it is important to know when and when not to dispose SharePoint objects. If you do not dispose objects in SharePoint, your server will run the risk of memory leaks which can lead to performance issues. If you dispose objects that you’re not supposed to call Dispose() on, you might inadvertently kill the SharePoint application! For example, the following code will definitely kill the SharePoint Web application:

SPContext.Current.Web.Dispose(); // expect calls to your help-desk with this line in your code!

If you are the custodian of the SharePoint farm, you might want to use the SP Dispose Checker Tool to ensure that the custom .NET assemblies being installed on your farm will not cause memory leaks.

For complete guidance on when and how to dispose SharePoint objects, you can read the SP Dispose Team blog.

Here’s what happened. Apparently, due to security policies set forth by the organization, all Oracle connections must time-out (Oracle session status=”SNIPE”) if the connection has exceeded the “Idle Time” specification in the Oracle Profile. Without getting deep into Oracle, the server will kill the connections after the Idle Time limit. I actually had our Oracle DBA helped me diagnose the problem. The Oracle DBA set traces and we monitored the Oracle sessions. That’s when I saw that even if initially, the application will keep several connections open (connection pooling is turned on for the OracleConnection object and you will see INACTIVE status in the Oracle sessions–inactive is okay–it just wasn’t executing commands at that time), after several minutes (15 minutes is the set Idle Time), the Oracle sessions would disappear. In a few rare occassions, we actually saw the Oracle sessions for the app time-out. The sessions appear with a “SNIPE” status for a little bit and then the server eventually cleans them up.

Is this behavior reproducable? Absolutely! Create an Oracle Profile (get your DBA if you don’t have rights to do this) and set the Idle Time to a short interval like 5 minutes. Next, associate the Oracle user-name that the application will use to the profile that has the 5-minute Idle Time limit. Run the app and you should be able to connect to Oracle. Wait like 10 minutes; your next call will generate the Oracle errors. Another way to reproduce this is the run the app for the first time and then watch the Oracle sessions. Kill the sessions created by the app. You will get “ORA-00028: your session has been killed” instead of the “idle time exceeded error”. But the following Oracle commands after that error will now generate the “not logged on” error. The ODP.NET pool manager gave the application a connection that should have been discarded because it’s already dead!

The ODP.NET provider will keep threads in the pool even though the server has already killed them! What’s the fix? The fix is a parameter that you need to add to your connection string. On my Oracle connection string, I only specify Data Source, User Name, and Password; no other parameters. I added an additional parameter called Validate Connection and you have to set it equal to True. I googled all day to find what this does. You can learn more out about this at the Oracle site. When you say Validate Connection=True on the connnection string, the ODP.NET connection pool will test the connection first before it returns the connection to the requesting app. The connection string look something like:

<add key="connectionString"
     value="Data Source=ORCL;
            User ID=me;
            Password=myPassword;
            Validate Connection=True;" />

 By putting Validate Connection=True on the connection string, connectionObject.Open() will get you a connection that is either:

• Valid open connection from the connection pool
• A fresh new connection the connection pool

You’ll stop getting crappy, dead connections from the pool. What’s downside? The pool manager will now ping the Oracle server using the connection first (to test if it’s still valid) before it returns to the application. A small price to pay I say to make the application stable.

I’ve tested using the Validation Connection=True method and it works. I can kill sessions in Oracle and the app will just re-open valid connections. The Oracle instance can be shutdown and restarted–when it restarts, the pool will simply create new database connections. Another possible approach is to set the Connection Lifetime parameter to a time value that is below the Idle Time limit in the server. In theory, this method will make the ODP.NET connection pool will discard the connections before the server kills it. My only problem with this latter strategy is that this doesn’t take into account Oracle server “bounce”, firewall disconnects, physical disconnects and the like. Just go with the Validate Connection parameter–it is still application pooling; just a bit busier.

NOTE: the stuff I wrote above is applicable to ODP.NET only. The System.Data.OracleClient namespace also has OracleConnection, OracleCommand, and adapter and reader objects as well. But they’re not the same. The System.Data.OracleClient, by default, does not use application pool. I tested this several times, again, by monitoring the Oracle sessions. If you put Pooling=True in your connection string, then the application will use connection pooling. What happens when the sessions are killed or sniped and you are using System.Data.OracleClient.OracleConnection in you app? First, you get “ORA-00028: your session has been killed” just like in ODP.NET. The difference between System.Data.OracleClient and ODP.NET OracleConnection is that in the former, it’s smart enough to not keep giving the cut-off connection back to application. You’ll get ORA-00028 error once and the succeeding calls should be fine. ODP.NET on the other hand, will keep that bad connection in the pool even though it’s been bad for a while; only when the ODP.NET connection has exceeded it’s TTL that it is removed from the pool.