in

Dot Net Mafia

Group site for developer blogs dealing with (usually) .NET, SharePoint 2013, SharePoint 2010, Office 365, SharePoint Online, and other Microsoft products, as well as some discussion of general programming related concepts.

This Blog

Syndication

Archives

Corey Roth [MVP]

A SharePoint MVP bringing you the latest time saving tips for SharePoint 2013, Office 365 / SharePoint Online and Visual Studio 2013.

December 2007 - Posts

  • LINQ to SQL Under the Covers

    With the release of the 3.5 extensions to the framework, there has been a lot of talk about LINQ and with it LINQ to SQL. Well I was interested in more how LINQ to SQL actually worked so I decided to take a look at some of the files it generates in the process and talk about them. When it comes down to it, in a lot of ways LINQ to SQL is just a glorified typed dataset with the power of LINQ behind it. Microsoft refers to it as an OR/M tool but everything is abstracted by the designer which means you can't create your own classes. This makes you completely data centric. Which is obviously fine for some situations, but not in all. Again, I am writing about what I am seeing and making some speculation, so if I am wrong, feel free to leave a comment and correct me like the noob I am.

    I am not going to discuss how to use LINQ to SQL today since Scott's 9 part series of posts on it does an awesome job of getting started with it. I am going to talk about what it actually does under the covers. When you first, create a new LINQ to SQL Class, you will immediately notice it looks a lot like the designer for the ASP.NET 2.0 DataSet. You can drag over tables just like you do with a dataset. Behind the .dbml file of your LINQ to SQL class is a .dbml.layout file and a .designer.cs file. The layout file simply keeps track of where you put things in the desginer. The .designer.cs files is a bit more interesting. This is where your DataContext is created as well as classes for the tables you drug into the designer.

    In the designer.cs file you will see multiple classes (a DataContext and one for each table you added). You'll immediately notice that it's a lot cleaner than the code behind of a typed DataSet. The DataContext class presents the means for LINQ to actually access the database and get the data you need. When you start looking at the autogenerated classes for your tables, you will find it has attributes similar to what you see on other OR/M. Here is what a class definition looks like.

    [Table(Name="dbo.SecureColumns")]

    public partial class SecureColumn : INotifyPropertyChanging, INotifyPropertyChanged

    A typical property has attributes that tell it where in the database the column is mapped to. It also calls events before and after the property changes.

    [Column(Storage="_Id", AutoSync=AutoSync.OnInsert, DbType="Int NOT NULL IDENTITY", IsPrimaryKey=true, IsDbGenerated=true)]

        public int Id

        {

            get

            {

                return this._Id;

            }

            set

            {

                if ((this._Id != value))

                {

                    this.OnIdChanging(value);

                    this.SendPropertyChanging();

                    this._Id = value;

                    this.SendPropertyChanged("Id");

                    this.OnIdChanged();

                }

            }

        }

    For the most part that's really all there is too it. I really wish it had support for you to map things to an existing domain object, but unfortunately there is nothing like that presently. Will people actually use LINQ to SQL? Who knows? You don't have a lot of control of the domain object it produces, but you can always extend them using partial classes. It definitely is a lot more feasibly to extend these than the crap that a typed dataset produces. What do you all think? Does LINQ to SQL have a chance?

  • I survived MOSS SP1

    As you might have heard, Service Pack 1 came out for WSS 3.0 and MOSS 2007. Since I am highly interested in the new supposed AJAX support, I installed it on one of my virtual machines and found the process pretty painless. The main thing you have to do is install SP1 for WSS 3.0 first and then install SP1 for MOSS. You have to do both. The process took probably half an hour tops and when it was done, I was please to see that my sites still came up and everything appears to be working. I know some people are apprehensive about installing any kind of service pack, so I hope my positive experience can calm some nerves.

    I hope to try the AJAX support soon once I install it onto a server that actually has some AJAX code on it (I am just not feeling motiviated to write some new code and put it on this VM). Anyhow, I am hoping the AJAX support works since I found many cases where UpdatePanels simply did not work in SharePoint. I'll post an update as soon as I try it.

  • Cowboy Coding a Data Editor with ASP.NET Dynamic Data

    The ASP.NET 3.5 Extensions Preview came out this week. The biggest feature people are of course talking about is the MVC framework. I won't be talking about that today since ten thousand other people already are. Today I will be talking about a new feature called ASP.NET Dynamic Data. This seems to be an effort to produce what Ruby has had for a while in the terms of scaffolding. I decided to try it out and found I was able to create an editor for a table very quickly with very little code.

    You start by creating a web site based upon the dynamic data template. It creates several pages for you which serve as templates for displaying and editing data. The default page has just two controls on it a DynamicGridView and DynamicNavigatorDataSource. This works quite a bit different than traditional datasources. The first thing you will notice is that there is nothing like a traditional SqlDataSource or connection strings or anything in the page itself. Instead, it works by automatically binding to whatever DataContext class you create using LINQ to SQL. So I created a new LINQ to SQL data context and drug my tables onto it and saved it. I then built the web site and it immediately gave me a list of tables I had specfied in my data context and allowed me to view and edit things right away. I didnt even have to tell the controls which data context to use.

    Most of what I discovered about this so far have just been my observations from working with it, so if I state something wrong, I apologize. Out of the box there are a series of aspx pages that are used as templates to display the data in different states. These can be easily customized. You can also customize how fields are rendered and provide validation. There is a section in the web.config where you can specify which template file to load for which situation (i.e.: list, details, etc.).

    This is defintiely worth checking out when looking for something to meet your simple data editing needs. Obviously iti is not a replacement for something custom you are going to put in front of a typical end user. However, it can be great for things like simple administration pages where you need to provide administrators a means of doing simple data editing.

    One other thing to note is that the interface pretty much provides full control to do anything to any of the tables that are in your data context class, so be careful with what you put in there. I think you can customize this, but out of the box, you can do pretty much anything.

  • The DataSourceID of 'TopNavigationMenu' must be the ID of a control of type IHierarchicalDataSource. A control with ID 'topSiteMap' could not be found.

    Today's topic is how to resolve the following error.

    The DataSourceID of 'TopNavigationMenu' must be the ID of a control of type IHierarchicalDataSource. A control with ID 'topSiteMap' could not be found.

    Go ahead, search Google for it. Good luck because you won't find a thing on it until this article happens to get indexed. It's actually not terribly difficult to fix once you know where to look. More than likely you got this after deploying a feature with some code in it. Seeing an error like that, you might think it has something to do with a master page, but in fact its not the case. Typically, you run into this error when working in partial trust (but it can occur in full trust as well).

    So what's the cause? The cause is that you added something and it is preventing SharePoint from entering SafeMode. How do I know this? Event Log? Nope, it doesn't give you any info. Well it gives you some. You might notice an event that states Safe mode did not start successfully. I saw this several times when I was attempting to solve this issue, but there is no additional information. So I starting sifting through a lot of logs. If you didn't know SharePoint actually logs quite a bit of stuff to the logs folder (C:\Program Files\Common Files\Web Server Extensions\12\LOG by default). Look for the last log file scroll to the bottom and then start working your way up. If you search for safe mode you will more than likely find something. In my most recent case I saw a couple of lines like the following.

    SafeControl load exception:Infragistics2.WebUI.UltraWebGrid.ExcelExport.v7.2, Version=7.2.20072.61, Culture=neutral, PublicKeyToken=7dd5c3163f2cd0cb Exception: Could not load file or assembly 'Infragistics2.Excel.v7.2, Version=7.2.20072.61, Culture=neutral, PublicKeyToken=7dd5c3163f2cd0cb' or one of its dependencies. The system cannot find the file specified. Safe mode did not start successfully. Could not load file or assembly 'Infragistics2.Excel.v7.2, Version=7.2.20072.61, Culture=neutral, PublicKeyToken=7dd5c3163f2cd0cb' or one of its dependencies. The system cannot find the file specified.

    Here it specifically states that it cannot load a particular DLL (No crap for using Infragistics please). In this case a new DLL was added but didnt make it into the deployment package. I simply added the file to the package and redeployed and ensured it made it to the bin folder and then everything worked fine. If you are using partial trust (and you should be), you can also run into this error if the assembly you are using does not have the proper CAS policy applied to it.

    I hope this helps. It really caused our team quite a few problems from time to time until I learned how to resolve it. With most SharePoint things there wasn't a single thing in Google that helped me resolve it either. This is why I am posting this in hopes that it will the next person that runs into the issue.

2015 dotnetmafia.
Powered by Community Server (Non-Commercial Edition), by Telligent Systems