Corey Roth [MVP] : ASP.NET

301 Redirects in .NET 4.0

CoreyRoth — Fri, 28 Aug 2009 14:46:48 GMT

I posted in the past how to do a simple search engine friendly redirect using the 301 HTTP status code. I thought this was always something that needed to be included in the framework and it looks like it finally will be in .NET 4.0. I saw this mentioned in Scottgu’s post about multi-targeting and thought it was worth mentioning today since I have posted on it in the past. To do a 301 redirect, use the new RedirectPermanent() method on the response object. It takes the same parameters as the Redirect() method. Here is what it would look like.

Response.RedirectPermanent(“/SomeOtherPage.aspx”);

This type of redirect obviously doesn’t really matter for internal sites, but for public facing sites, if you are relying on a redirect somewhere, it is best to do it with a 301 as the search engines don’t really care for the standard 302 redirect. At least they didn’t at one time. I am not SEO expert.

Follow me on twitter.

Compilation Error with Generic Handler in Visual Studio 2008

CoreyRoth — Mon, 27 Jul 2009 22:04:27 GMT

Anyone else out there notice that if you add an generic handler to your project that it won’t compile? It appears to be an issue with the template included in Visual Studio and it may have been resolved in a service pack but currently I don’t think so. The file type I am describing is the .ashx generic handler and not the ASP.NET Handler as you can see below.

After it creates the file you might immediately notice there are issues. If you go to compile it, you’ll get errors like seen below.

Luckily, resolving the error is quite easy. You just need to add System.Web.Services to your using block. Once you do that, you can compile successfully and begin building your handler. I just thought I would point this out since I have seen this on multiple systems now.

Troubleshooting the DelegateControl

CoreyRoth — Thu, 02 Apr 2009 17:28:03 GMT

I’ve have been using SharePoint’s DelegateControl a lot again lately. If you are not familiar with it, it allows you to drop a placeholder on a page and then later specify what control goes in it by activating a feature. You can effectively use it as an alternative to the SmartPart for putting user control’s on pages when you are deploying custom pages (i.e.: in a site definition or via publishing). However, one thing I have discovered is that if something goes wrong with the delegate control, there is absolutely zero feedback on the page to let you know that your control could not be loaded. It simply just displays the page without your control.

This is pretty annoying, but it is pretty easy to figure out what the issue is. As I have said many times in the past, the LOGS folder in the 12 hive is your friend. Most issues you have in SharePoint can be resolved by taking a look at this folder. For my latest issue, I opened up the latest log file, to find the following entries.

04/01/2009 14:56:21.98 w3wp.exe (0x6DA4) 0x6980 Windows SharePoint Services General 8e1n High Failed to create a user control from virtual path '/_ControlTemplates/MyControls/MyControl.ascx': Type 'System.Web.UI.WebControls.ListView' does not have a public property named 'ItemSeperatorTemplate'.

As you can see in my case, I was stupid and misspelled ItemSeparatorTemplate on my ListView control. This caused my control to throw a runtime exception. In a way I guess you can argue that this is nice, because the DelegateControl caught the exception and the entire page didn’t die with a yellow screen. However, it would be nice if the error could be reported without having to dig through the LOGS folder. Just remember any unhandled exception your user control might throw will cause the delegate control to display nothing. If you want more information on the DelegateControl, MSDN has some decent information on it.

Follow me on twitter.

Introduction to SharePoint Development: Deploy a User Control in SharePoint

CoreyRoth — Tue, 18 Nov 2008 20:07:58 GMT

A common question I get with new SharePoint developers is "How do I deploy my user control in SharePoint?". Many times they know of the SmartPart or even how to make their own, but its the matter of deploying things that may not be clear. Before starting this, you need to read how to build and deploy a web part. Many of the concepts in that article are used here and explained in more detail.

To build a user control, you start in very much the same way as you do with regular ASP.NET. My recommendation is to start by creating a web application project. You can also use a regular class library, but its easier if you use a web application project since it has the file types you need as well as references. If you already have a class library, you can easily convert it to a web application project using a hack.

Once you have a web application project, create your user control as normal. Build the project and then its time to deploy. We'll first talk about where the files go on the server and then we'll look at how we can get the files there with a solution package. Let's assume, I have a control called MyControl.ascx. This file has to be deployed to the SharePoint server along with its binary. If you are using a SmartPart, the ascx file to go is in a folder called UserControls located in the root of your web sites folder (by default c:\inetpub\wwwroot\wss\VirtualDirectories\80). However with true SharePoint development you have to break the my controls go in X folder on my site way of thinking. In SharePoint, everything is designed to be modular no matter how many web applications your server hosts.

I recommend creating your own web part to host your user control that will work with any folder. SharePoint itself puts all user controls in the CONTROLTEMPLATES folder in the 12 hive (C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12). You can place your controls here as well, but I recommend creating a subfolder here to keep your controls separate. In this case, I will create a folder called MyControls and copy MyControl.ascx into it. At this point you are probably wondering what is the path to my control if its in the 12 hive? On any SharePoint web application, there is a virtual directory called _controltemplates. This happens to map to the folder we need. Therefore, the path you would reference in your web part (or any web page) would be ~/_controltemplates/MyControls/MyControl.ascx.

Now, it is just a matter of deploying the binary. In traditional ASP.NET, you could just copy the DLL of your web application project to the bin folder of the web application. However, with SharePoint we can't do that without specifying Code Access Security which is a pretty big undertaking when you are starting out. For any file that is in the bin folder, SharePoint requires a security policy be set specifying exactly what permissions your DLL has. I recommend deploying to the bin folder, but if you are just starting out, you don't want to go there yet. To get around this for now, there are two options: 1) Change the TrustLevel in the web.config to Full or 2) Deploy the DLL to the Global Assembly Cache. I strongly recommend against #1, so for the sake of starting out, just copy your DLL to the GAC. You will need to strongly name your assembly. Any time you copy the DLL to the GAC, you will need to either recycle the application pool that your web application is using or reset IIS. I know that can be a pain, but once you implement CAS, you don't have to do that any more.

Just like with a web part, you have to add your user control as a safe control. Just specify the assembly name and allowed namespaces.

</SafeControls>

At this point you are ready to try your new user control out. To add it to a page like a web part, I recommend you follow the steps in this post to make your own SmartPart. If you don't know how to deploy a web part, follow my post on how to deploy a web part. Once you have your smart part added, specify the path I mentioned above (~/_controltemplates/MyControls/MyControl.ascx). You can also add user controls to your master pages, just like you would in ASP.NET. Just create the reference and add it to the .master.

This may sound like a lot at this point but it's really not bad. If there is enough interest in the article, I will try and get some code together in one package so people can use it as a starting point. That is how you manually deploy a user control, we'll move onto how we do it with a solution package.

Deploying via Solution Package

For deployment, we will pretty much follow what we did in the deployment of the web part. For more details on building solution packages, please see that post. In this case a feature is not necessary unless you want to automate the deployment of the user controls onto an existing page. The cab.ddf file only contains lines to copy the binary and .ascx file.

; ** MyControls.wsp  **
.OPTION EXPLICIT     ; Generate errors 
.Set CabinetNameTemplate=MyControls.wsp     
.set DiskDirectoryTemplate=CDROM ; All cabinets go in a single directory
.Set CompressionType=MSZIP;** All files are compressed in cabinet files
.Set UniqueFiles="ON"
.Set Cabinet=on
.Set DiskDirectory1=Package

Solution\manifest.xml manifest.xml

;binaries
bin\MyControls.dll MyControls.dll

;feature files

;template files
MyControl.ascx CONTROLTEMPLATES\MyControls\MyControl.ascx

The Manfiest.xml file will contain entries to copy your ascx file out as well as copy your binary to the GAC. It will also add the Safe Control entry that you need. Here is what the file would look like. The TemplateFile element is used to specify every .ascx file that you want copied to the server. More details on what you can do with the manifest file are here.

<Solution SolutionId="{FA34A0BE-FEAA-4750-9E82-B313F62C5CF9}"  xmlns="http://schemas.microsoft.com/sharepoint/" ResetWebServer="true">
  <TemplateFiles>
    <TemplateFile Location="CONTROLTEMPLATES\MyControls\MyControl.ascx" />

  </TemplateFiles>
  <Assemblies>
    <Assembly DeploymentTarget="GlobalAssemblyCache" Location="MyControls.dll">
      <SafeControls>
        <SafeControl Assembly="MyControls, Version=1.0.0.0, Culture=neutral, PublicKeyToken=03afd371f1d50a3a" Namespace="MyControls" TypeName="*" Safe="True" />
      </SafeControls>
    </Assembly>
  </Assemblies>

</Solution>

At this point, you build and deploy the .wsp file as described in my web part post. Again, I strongly recommend reading that post if you are not familiar with any of the deployment steps yet. The nice thing about having your user control in a solution package is that it is now completely portable. It can be deployed to your other SharePoint servers very easily. Once you have mastered the process, I recommend you start deploying your binaries to the bin folder with Code Access Security. Once you have the solution package built, adding CAS is pretty easy and it saves you from having to kill your app pool every time you do a deployment.

Updating Data with LINQ to SQL and GridViews when using a View

CoreyRoth — Tue, 07 Oct 2008 18:27:59 GMT

Look! It's a post that isn't about SharePoint! Today, I want to talk about some of the issues I have run into when trying to update data using a GridView when bound to a LinqDataSource. This data source has an EnableUpdate property, but unfortunately there is more to it than just that. It works pretty well, but there are a few things that you have to do otherwise you will get the following error.

The Entity is not of the correct type.

In today's example, I required a stored procedure to do the update because I was updating multiple tables behind the scenes. Although LINQ can do this, the complexity of the update was simpler if I did it via stored procedure. The data I am displaying in my GridView is based off a database view. The first thing to do is drag the View into your LINQ to SQL class. You need to make sure your view includes a primary key. You then need to select the column and mark it as a Primary Key in the LINQ to SQL designer. After you have your view defined, drag the stored procedure for your update into the designer. Then on the properties of your view's data class, you can set a default method for Insert, Update, and Delete. In this case I am only worrying about Update. If you click on Update, it will bring up a Configure Behavior window which will allow give you two choices. Use Runtime will dynamically generate the CRUD logic at runtime. In our case though, we will choose Customize and then pick our stored procedure out of the list.

After you have selected an update method, your LINQ to SQL class is good to go. You are now ready to build your page. Start by dragging a GridView and LinqDataSource onto your page. On your LinqDataSource, set the EnableUpdate property to true. Use the wizard to bind your LINQ to SQL database. Pick the Entity named after your view but when configuring columns be sure and choose all columns (*). If you select individual columns, it populates the Select property on the LinqDataSource and you will not be able to make updates. At this point, you can bind your GridView to your LinqDataSource. If you have followed all of the steps so far, the Enable Editing option should be available for you to check. Check it and then the last thing you have to do is set the DataKeyNames property on the GridView. Set it to the name of your primary key and you should be ready to make updates using a GridView.

I always find that I spend more time than I care to setting up GridViews. Hopefully this will help if you ever need to use LINQ to SQL with a GridView. Also don't forget Tulsa TechFest this week where I will be talking about Code Access Security in SharePoint.

How to: Use LINQ to SQL without using the Object Relational Designer

CoreyRoth — Tue, 18 Mar 2008 00:54:20 GMT

LINQ to SQL has already proved to be extremely easy to use to create object relational mappings when you have an existing database schema using the Object Relational Designer. This designer is good, but you may not want something that is autogenerating your domain classes. You may want to generate your domain classes yourself. This is actually quite easy and works in a similar manner to other OR/Ms such as ActiveRecord. The thing I like about it is that your domain objects do not have to inherit from some base class that has all of the underlying logic to access the database. Instead you create a custom class separate from your domain objects that inherits from DataContext.

We'll create a simple example of a products table for an e-Commerce web site. Let's start by looking at the domain object. Before you create your domain object start by adding a reference to System.Data.Linq to your class library if it is not already present. You will then need to add a using statement in each domain class for System.Data.Linq.Mapping.

[Table(Name="Products")]
public class Product
{
    [Column]
    public string Name;
 
    [Column(IsPrimaryKey=true, Name="Id")]
    public int ProductId;
 
    [Column(Name="Price")]
    public double Price;
}

The first thing you do in your domain class is decorate it with a Table attribute. An optional parameter here specifies the name of the underlying database table. In this case my domain object it Product but my database table is named Products. I then defined three properties representing columns in the table. The Column attribute specifies that the property will have a corresponding column in a database table. The IsPrimaryKey parameter specifies that the column is a primary key in the database. The Name parameter here also allows you to specify a different column name in the database.

That is really all that is required to create a domain object. You can define a class for each domain object you want and you can also create relations between them (but I won't be covering that here today). Once you have your domain object created, you will need to create a DataContext class to actually be able to query your domain objects. This is also pretty simple. You just expose a property with the generic type of Table<> for each one of your domain objects. The name of the property is what you will use with the DataContext when you are querying with LINQ.

public class StoreDataContext : DataContext
{
    public Table<Product> Products;
 
    public StoreDataContext(string connection)
        : base(connection)
    {
    }
}

Now that you have your domain objects written you will need to create the SQL tables that they represent. You can do this manually, or you can have LINQ create the whole database for you. Just create an instance of your DataContext and call the CreateDatabase method. This method infers the name of the database given the connection string you used. If you did not specify the database, you need to add a Database attribute with the name to your class.

StoreDataContext myDataContext = new StoreDataContext(myConnectionString);
myDataContext.CreateDatabase();

Alright, so now your domain objects and database are created, now you just need to query something with it.

var products = from product in myDataContext.Products
               where product.Price > 49.99f
               select product;

This simple query simply returns any product with a price greater than 49.99. So, LINQ to SQL doesn't have to be completely domain driven. This gives you a lot of flexibility and makes it easy to add additional things to your domain logic if you want to. The downside to this of course it that, when your database schema changes, your domain object is not going to get updated at the click of a button. If you are building your domain objects in this manner though, this is probably not a concern to you though.

How to: Hack a Class Library Project into a Web Application Project

CoreyRoth — Fri, 22 Feb 2008 20:09:24 GMT

Kind of a weird tip here, but I have ran into a situation where I have needed to do this. Basically, I have had an existing class library (for SharePoint development) and for some reason, I have decided I need to add ASP.NET file types to it (i.e. User Controls, Master Pages, etc.). A class library doesn't have these file types in the Add Item menu so you need a Web Application Project. When it comes down to it a Web Application Project really is the same thing as a class library, it just has some extra settings. So when it comes down to it, you would either have to recreate the project and add your existing files back into it or just hack the XML of your .csproj file. I obviously prefer the latter.

To do this, start by Unloading the Project by right clicking your project and choosing Unload Project. Next Right click on your unloaded project and choose Edit <PrjectName>.csproj. Paste the line below in the first ProjectGroup element. Usually Visual Studio puts it underneath the ProjectGuid element.

<ProjectTypeGuids>{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}</ProjectTypeGuids>

That is the only change that is required. There are some optional settings that you can put in regarding the configuration of Cassini, but none of them are required to get you going. You can always configure them in Visual Studio. Once you have made the change, save the .csproj file and Reload Project. Once the project is loaded, all of the ASP.NET file types will be present in your Add Item menu. When you compile, it will still compile everything down to a single DLL and you can deploy it just as if it was a regular class library.

SPSqlDataSource: This control does not allow connection strings with the following keywords: ‘Integrated Security’, ‘Trusted_Connection’.

CoreyRoth — Mon, 11 Feb 2008 16:28:00 GMT

I ran into this one again lately when deploying. We are folowing best practices with our connection strings by using Integrated Security. We have several controls on the web site making use of SqlDataSource controls. However, at runtime, we are left when an error like the following.

Microsoft.SharePoint.WebPartPages.DataSourceControlDisabledException: This control does not allow connection strings with the following keywords: ‘Integrated Security’, ‘Trusted_Connection’.

This is because SharePoint puts a tagMapping in the web.config that maps the ASP.NET SqlDataSource to its SPSqlDataSource. Why it does this, I have no idea? If I check the SDK on that class, there is not so much as even a description of what the class does (come on Microsoft, you still need to work on this SDK documentation). A workaround is actually pretty simple, remove the tagMapping. However, you can't just simply delete the line, you must use the remove element to get rid of it.

This will allow the control to work, but you also need to register the ASP.NET SqlDataSource as a safe control. You know the syntax, but here it is in case to make it easy.

That is all it takes and everything inside SharePoint still seems to work. My point of today's post is to put out the following questions.

What is the purpose of this inherited control?
Why on earth would it not support integrated security?
Why does the SDK documentation continue to leave out details about key classes?

If you have the answer to any of those, please leave a comment.

Binding a GridView to a Generic List of Primitives

C-Dog's .NET Tip of the Day — Fri, 21 Sep 2007 20:00:18 GMT

I have often bound GridViews to my own custom objects. However today, I needed to bind a GridView to a List<string>. I needed to customize the columns a bit and I soon realized I did not know what to specify as a DataField. I tried Item and just...(read more)

How to expand a TreeView to the current page when using a SiteMapProvider

C-Dog's .NET Tip of the Day — Wed, 25 Jul 2007 13:59:23 GMT

Ok, well I started writing this post yesterday and somehow I accidently closed my browser and lost the entire contents of the post, so here I am at it trying it again. Lately, I have been working with a TreeView to handle hierarchical naviagation. Specifically...(read more)

Hate Repeaters? Try a ListView!

C-Dog's .NET Tip of the Day — Mon, 02 Jul 2007 17:31:44 GMT

Repeaters have always been a necessary evil. They are simply the only practical way to do custom formatting when binding to lists of data. Oddly enough, it turns out that not everyone just wants to display a grid of data. In the past, by using the repeater...(read more)