Archives

Archives / 2004 / September

  • Testing .NET updates across the enterprise?

    2 Comments

    A question today for the bloggers (and readers) out there.

    With a size of the organization I work for (7000+ desktops, 120+ servers) it's hard to do a lot of acceptance testing when something like say a .NET patch/upgrade comes out. With hundreds of web apps out there, there's no telling what will break and what won't and frankly, individual testing on each app is just unobtainable given time and budget constraints the business usually is under.

    So the question is, when something like an update comes out how do you test across the entire enterprise to an acceptable level of comfort? Imagine the scenario if/when the .NET framework is updated from 1.1 to 1.2 (or even the large switch we'll have to make to 2.0). You have hundreds of web apps written in .NET out there. Presentation, business, and data tiers all depending on the framework. It's impossible to run through a manual testing effort on each app. In a perfect world, every app would have a good set of Unit tests which you could run.

    However the testing effort is really around making sure the framework doesn't break something in the environment, but how do you test for something like this? How do you be proactive rather than reactive? How do you mitigate risks with such an update and make the environment management people happy with the change? Thoughts, ideas, comments?

  • Customizing SharePoint Sites and Portals

    No Comments

    Not much of a blog this entry as it's just an aggregation of Microsoft content. I thought however people would be interested in the full set of articles published on the subject of customizing SPS.

    Part 1 : Introduction
    Part 2 : Using Templates and Site Definitions
    Part 3: Style Sheet Class Reference Tables

    PS I haven't got much response from my "What have you done with SPS and get a free gmail account" so I guess that's a bust. I wonder if I had offered up a free copy of Visual Studio.NET Enterprise Architect I would have got a better response?

  • GMail Invitations up for grabs

    1 Comment

    Okay. I have 5, count them 5, GMail invitiations available to the first few lucky participants. However, you're going to have to work for your 1 gigabyte of free webmail storage.

    Send me a note on how you used SharePoint in your environment (or for a client). Not just an out-of-the-box install but how you leveraged SharePoint to deliver a business need. The more interesting the better. Screen grabs are great too. Top 5 creative uses of SharePoint get the invites. I'll post the winners on this site in a couple of weeks so submitting your entry means that it may be published.

    Now is that so hard? Okay, so it might blow up in my face and nobody is using SharePoint in a creative way but hey, what the heck. Submit your creative creations (zipped or direct me to a public link) to me via email.

  • Session.SessionId is *not* unique

    1 Comment

    A co-worker of mine was trying to detect whether his session expired in an ASP.NET application. Before he discovered Session.IsNewSession, he was using the SessionId variable and comparing it to hidden values and whatnot. He had assumed that when a page was reloaded after the session expired, that a new SessionId would be created. This is not always true.

    There's a countdown timer (by default, 20 minutes) that fires from the first request for a users session. If there is another request efore the timer reaches zero, then it resets the counter and begins again. When it reaches zero, the Session_End event (in global.aspx) is fired, not because of a request but because the timer ran out.

    Session.SessionId might be the same on a postback or page reload. If you're not writing any data to the session, ASP.NET will reuse the Id because from it's perspective it hasn't changed so why create a new one (id, not session)? Session.SessionID is generated in RAM on the server and not a persistent property. It's unique at the time is it created, but not guaranteed to be unique over the course of time. For example, if IIS is restarted it may restart the numbering sequence.

    So use Session.IsNewSession to determine if it's a new session or not. Use Guid.NewGuid() to create something unique (you can store this in a Session variable and check for it later if you want).

    There's a great FAQ on ASP.NET session here in case you're interested.

    Happy coding...

  • Migrating sites from dev -> acceptance -> prod

    1 Comment

    One thing that comes up quite often is "How do I keep all the work I've done in development and move it to acceptance/production" with SharePoint? Luckily there's a nice command line tool that's bundled with SharePoint to do this.

    SMIGRATE is a tool that can restore sites and move them from SharePoint Team Services (STS) into the new 2003 versions. It can also help you migrate sites from one server to another (or to the same server) in 2003 directly. This blog talks about using it for migration from a development environment to your production one (or test if you prefer).

    SMIGRATE works wonders because a) it migrates all your data, including security and subsites b) you can execute it from any SharePoint server and restore to any server (you have to be SPS/WSS admin on both) c) is simple for moving all your hard work in development into acceptance or production. Using SMIGRATE is pretty straight forward.

    To backup a website:

    1. Enter the following at the command line:
      smigrate -w http://server[/site] -f filename.fwp -u domain\id -pw *
    2. This will prompt you for your NT password. Enter it at the prompt.
    3. Grab a coffee and wait.

    To restore a site:

    1. Create a new site through the portal site creation wizard. Note what the site url is.
    2. When you get to the point of applying a template, stop and close the browser.
    3. Enter the following at the command line from any SharePoint server (where siteurl is the url you used in step #1):
      smigrate -r -w siteurl -f filename.fwp -u domain\id -pw *
    4. Enter your password, grab a coffee, go for lunch or have a siesta.

    There are a couple of gotchas you should be aware of.

    1. When you migrate a site, the new site has to exist. If you've gone through the trouble of creating the site using something like the SPS site creation wizard you'll find you get the site created then try to migrate and it tells you a template has already been applied. The trick is that when you to the screen in SPS where you apply the template to the site, the site is already created. Go ahead and start your migration now and when you're done, the site will be there and ready to use.
    2. Make sure all your dataview web parts and 3rd party components are on the target server. There's nothing like migrating the site then trying to access it, only to find yourself staring at the maintenance page trying to remove invalid web parts. This is especially true of dataview web parts as they are sometimes picky about the pathing to the datasource, especially if you have it pointing at another list on the same site.

    In any case, the tool is a good friend to have so get used to it, try it out and make sure you understand what's going on before you start moving gigabytes of documents and lists onto your production boxes. There's also a good writeup on using the tool here and the online version of the Windows SharePoint Administrators Guide here.

    For those that are afflicticted with GUI-Itis and fear the command line, there's a graphical interface that Renauld Comte created. You can download the file directly from here (note, you still have to run this on your SharePoint server).

  • A clean way to brand your Portal

    4 Comments

    I see (and get) a lot of questions about customizing the look and feel of SharePoint Portal Server. More often than not, this leads to an answer of directly modifying the SPS.CSS files on the server. This always leads to the caveat that this file may be updated with a service pack install or software upgrade. There is a much easier and safer way to do this which will never break.

    In your SharePoint setup, Microsoft has provided a way to specify your own custom style sheet. If you know how style sheets work when a page is rendered, the last style specified (no matter how many style sheet files get loaded) always wins. This is by design but knowing this, and how SharePoint works, is a powerful combo that will let you cleanly mod your portal as much as you want without having to backup/restore files everytime your do an upgrade.

    When SharePoint renders it's portal pages it renders all of it's own internal stylesheets. These are (in order):

    1. ows.ccs
    2. menu.css
    3. sps.css

    Next, it renders any stylesheet you specify in the Site Settings page. Finally it renders the page content. Knowing this means that any style you put into your own stylesheet will override those specified in the Microsoft ones. So now you don't have to go modifying the base files to get the effect you want. Here's a simple example.

    Create a blank stylesheet. Put a single style in it. Let's override .ms-WPTitle which is the style used to render Web Part titles. Your stylesheet should contain this:

    .ms-WPTitle
    {
      background-color: black;
      font-weight: bold;
      font-family: verdana, arial, helvetica, sans-serif;
      color: white;
      padding-left: 6px;
      padding-right: 7px;
      padding-top: 2px;
      padding-bottom: 2px;
      font-size: 8pt;
      text-transform: uppercase;
    }

    This creates a style for the web part titles that displays a white uppercase title against a black background using Verdana as a font. Save this file as "mystyle.css" (or whatever name you want).

    Now you need to tell SharePoint to use this stylesheet.

    1. Select "Site Settings" from your portal
    2. Click on "Change portal site properties and SharePoint site creation settings" from the General Settings section
    3. The last option is for a Custom Cascading Style Sheet. Put in the location of your stylesheet you created above. An additional trick is to use SharePoint to store your own stylesheet so put it in the Document Library of your own portal. That way you don't have to deal with server administrators whenever you want to change your sites look and it gives you a simple document management process to keep tabs on who's working on this file. So our entry would look like this: "/Document%20Library/mystyle.css" (assuming you uploaded it to the site, otherwise use a fully qualilfied UNC to locate the stylesheet, maybe from your corporate web servers)
    4. Click OK to save the changes

    Now refresh the site in your browser. You should see the changes applied to all web parts on your site (Press F5 to refresh or you might have to do a "deep" refresh with Ctrl+F5). Continue to edit this file, making changes with your favorite style sheet editor like TopStyle (or Notepad if you prefer). In no time you'll have a custom stylesheet with the branding you want on your site.

    A variation on creating styles from scratch is to take a copy of SPS.CSS and modify the styles you want by changing your copy of this file. This uses the same technique as above (not modifying the file directly) but gives you a list of all the styles that SharePoint uses rather than building up from scratch. Pick whichever method works for you but the important thing to remember is that you don't have to touch the base SharePoint files.

    Two more quick tips. There's a list of the styles used with a visual reference in the SDK documentation available here. Also in that file is a short piece of Javascript that you can create and put into a content editor webpart to display the styles on the page when you hover your mouse over them. Both are valuable resources to help you when you're customizing your look.

    Note, this is only for SharePoint Portal Server. WSS sites need a custom theme which is a whole 'nuther post and a different technique that I'll walk you through if there's a desire.

  • Stored Procs vs. Dynamic SQL

    6 Comments

    Late last year, Rob Howard and Frans Bouma got into a fairly heated debate about this. Frans' position was that stored procs were bad, Rob wanted everyone to use them. This resulted in a fierce blog by Frans, a rebuttal by Rob and hundreds of other bloggers taking either side.

    Anyways, for me, it's back again. I'm rolling together several small applications and have come to a crossroads. Now understanding that I'm a working architect (i.e. a software architect that picks the hammer up once in awhile as opposed to the ones that just draw pretty pictures) so my TSQL is very limited and stored procs, well they're about as alien to me as anything. However the syntax isn't that odd (especially if you're writing simple sprocs) and there are too many advantages to pass it up.

    Now there's always a lot of debate of TSQL vs sprocs and performance. Sure, complicated SQL can be a dog's breakfast when it comes to performance and you can just hand your stored proc over to your DBA and ask him to optimize it (what else is he/she there for anyways?). People will argue that simple statements like a SELECT blah FROM blah WHERE blah = @blah shouldn't be in the database. Why not? And who can tell you that the simple SELECT statement will never change. It only took me a few minutes to grasp the stored proc syntax so it's not all that bad.

    As for things like SQL injection attacks or security, those things are always going to be an issue no matter where your code is. Just write good code and treat the database as a client rather than a consumer. There are some situations (like dynamic tables) where sprocs just fall down but I would take a closer look at your architecture. Do you really need dynamic tables or are you doing it to just cut down work imposed on you?

    So basically, I'm looking to use sprocs even in small projects because:

    • I don't want SQL Code in my application because I don't want an application to have to be recompiled when the database changes
    • The application is there to view or be served up by the data, not the other way around so I don't want the application to have complicated security even in a situation where it's needed. It's much easier to apply role based security to the data than to worry about screens and buttons and domain objects that restrict access.
    • I don't want to send a whack of unencrypted SQL across the network showing off my table names
    • Reusability. Having stored procs available across my enterprise cuts down on the amount of code the developer needs to write.
    • I can put together my sprocs and let my DBAs tune it independently of my application.

    I'm finding a lot of advantages by getting my SQL out of my codebase and I believe the benefits outweigh the long term costs of maintenance. Everyone should come to his or her own conclusions on what is right for them. My preference is to use stored procs for any data manipulation. Even simple SELECT, INSERT, DELETE statements are targets as you never know what optimizations your DBA can make. Your mileage may vary.