Friday, June 30, 2006
Flash video and IIS
Quick note: when serving flv files on a Windows 2003 server, remember to add the flv MIME Type: .flv video/x-flv
Thursday, June 29, 2006
NUnitAsp, ASP.NET 2.0 and Master Pages
I've been trying to use NUnitASP to write some test fixtures for http://www.oceg.org (registration process in particular), but for the life of me I couldn't get it to work. It just could not find any of my controls.
I thought maybe there was no support for ASP.Net 2.0 yet; the latest news I could find dated from Nov. 2005 and mentioned a future 2.0 release of NUnitASP with full .Net 2.0 support. Nothing after that.
I contacted Jim Shore (main developer of NUnitASP), and received the following email:
"Hi, Stephane,
The project isn't dead but it is significantly slowed down to my other commitments. You can get the latest code from CVS; that is pretty much what will be released as NUnitAsp 2.0 when the time finally comes."
Good to know! Well, I downloaded the latest version, and still no success. After digging a bit through the source, I realized there was no support for Master Pages. So here are 2 NUnitASP testers that will enable MasterPage and ContentPlaceHolder support:
http://http.oceg.org/public/MasterPageTester.zip
Both files go under NUnitAsp/AspTester. Use these classes in the same way you would drill down user controls in NUnitASP:
I thought maybe there was no support for ASP.Net 2.0 yet; the latest news I could find dated from Nov. 2005 and mentioned a future 2.0 release of NUnitASP with full .Net 2.0 support. Nothing after that.
I contacted Jim Shore (main developer of NUnitASP), and received the following email:
"Hi, Stephane,
The project isn't dead but it is significantly slowed down to my other commitments. You can get the latest code from CVS; that is pretty much what will be released as NUnitAsp 2.0 when the time finally comes."
Good to know! Well, I downloaded the latest version, and still no success. After digging a bit through the source, I realized there was no support for Master Pages. So here are 2 NUnitASP testers that will enable MasterPage and ContentPlaceHolder support:
http://http.oceg.org/public/MasterPageTester.zip
Both files go under NUnitAsp/AspTester. Use these classes in the same way you would drill down user controls in NUnitASP:
MasterPageTester masterPage =
new MasterPageTester(new WebFormTester(HttpClient.Default));
MasterPageContentTester contentPH
= new MasterPageContentTester("ContentPlaceHolder1", masterPage);
LinkButtonTester registerButton = new LinkButtonTester("SignUp_Registered_Button", contentPH);
Friday, June 23, 2006
ASP.NET 2.0 themes URL mapping
Here's a non-trivial ASP.NET 2.0 feature I've always taken for granted. Let's say you define a skin for an ImageButton web control, using an ImageUrl attribute relative to the theme.
<asp:imagebutton runat="server" skinid="MySkin" imageurl="Images/MyLinkButtonImage.jpg">
The skin is located in App_Themes/MyTheme/MySkin.skin.
The image is located in App_Theme/MyTheme/Images/MyLinkButtonImage.jpg.
Somehow, "magically", when applying the skin to an ImageButton instance the image URL gets mapped to whatever theme is being used. But when using my own controls, or even using 3rd party controls like the ComponentArt Web.UI control suite, this magic trick just doesn't happen by default. You need to add a special attribute to define your custom control public property as a URL property.
...
[Category("Appearance")]
[UrlProperty]
public string ImageUrl
{
get{...}
set{...}
}
...
That's it. Once you do this, URL mapping takes place automatically. If the URL is app-relative (starting with a "~/"), VirtualPathUtility automatically maps it. If it's theme-relative, it gets mapped to the theme being used when rendering the control.
<asp:imagebutton runat="server" skinid="MySkin" imageurl="Images/MyLinkButtonImage.jpg">
The skin is located in App_Themes/MyTheme/MySkin.skin.
The image is located in App_Theme/MyTheme/Images/MyLinkButtonImage.jpg.
Somehow, "magically", when applying the skin to an ImageButton instance the image URL gets mapped to whatever theme is being used. But when using my own controls, or even using 3rd party controls like the ComponentArt Web.UI control suite, this magic trick just doesn't happen by default. You need to add a special attribute to define your custom control public property as a URL property.
...
[Category("Appearance")]
[UrlProperty]
public string ImageUrl
{
get{...}
set{...}
}
...
That's it. Once you do this, URL mapping takes place automatically. If the URL is app-relative (starting with a "~/"), VirtualPathUtility automatically maps it. If it's theme-relative, it gets mapped to the theme being used when rendering the control.
ASP.NET 2.0 WebResource.axd and browser caching
We've launched our new public site (http://www.oceg.org) about a month ago now. Everything seems to be running smoothly, we're getting about 600 unique visitors a day, it's a pretty good start. However, we haven't been pleased with the overall performance. Page loads seemed abnormaly long, bandwidth useage unexpectedly high.
I found this neat little tool: Fiddler. Your can download it at http://www.fiddlertool.com. It's a debugging tool that catches every http request response sent/received by IE, with useful information about each one.
As I wrote in my previous post, we're using the ComponentArt Web.UI suite. Nice controls, but heavy javascript files. Since version 2006.1, those js files are serverd via WebResource.axd. That's a very nice addition, much easier to install, but Fiddler showed me that every WebResource.axd response had its caching set to "private", thus preventing caching to occur in the browser. Since we're using Menu and Grid together in a many pages, each client had to download at least 100KB of javascript upon every request!!
Workaround: I read Rick Strahl's post about this very same issue - http://west-wind.com/weblog/posts/4310.aspx. What you need to do is change the debug attribute in the compilation section of web.config to "false":
Caching is now "public", with expiration set to 1 year from original request date. I should be seeing our bandwidth useage shrink dramatically...
I also found some interesting info on Scott Gu's blog, like how to edit machine.config to ovveride the debug attribute on production servers. Cool stuff.
I found this neat little tool: Fiddler. Your can download it at http://www.fiddlertool.com. It's a debugging tool that catches every http request response sent/received by IE, with useful information about each one.
As I wrote in my previous post, we're using the ComponentArt Web.UI suite. Nice controls, but heavy javascript files. Since version 2006.1, those js files are serverd via WebResource.axd. That's a very nice addition, much easier to install, but Fiddler showed me that every WebResource.axd response had its caching set to "private", thus preventing caching to occur in the browser. Since we're using Menu and Grid together in a many pages, each client had to download at least 100KB of javascript upon every request!!
Workaround: I read Rick Strahl's post about this very same issue - http://west-wind.com/weblog/posts/4310.aspx. What you need to do is change the debug attribute in the compilation section of web.config to "false":
Caching is now "public", with expiration set to 1 year from original request date. I should be seeing our bandwidth useage shrink dramatically...
I also found some interesting info on Scott Gu's blog, like how to edit machine.config to ovveride the debug attribute on production servers. Cool stuff.
Firs post (hello world)
This is my first post, so first here's a quick introduction to this blog, what I'll be talking about, and our purpose.
I am the CTO of the Open Compliance and Ethics group, a non-profit organization whose mission is to integrate corporate governance, risk management and culture. In short we deal with business ethics; our goal is to provide a solid, flexible framework that will prevent future Enron-like collapses.
This blog will not be particularly focused on corporate ethics, but rather on our technolgy research, findings, ideas etc...
After looking thoroughly at different CMS packages (and there are are a lot of really good ones out there), we decided a year ago to develop our own knowledge portal. Why? Well, we use a pretty well-defined and complex data schema to create our guidelines and practices, and couldn 't find an easy way to port our existing data and reports to an off-the-shelf product. Also, because our knowledge portal is both a development tool and a way for members to access content, we needed a very robust aand complex permission system.
Our web site URL is http://www.oceg.org. It's still a work in progress, but we've gone a long way over the past few months.
Here's a quick tech overview:
- Database: SQL Server 2005
- Middleware: C#.Net 2.0
- Front-end; ASP.NET 2.0, themes, web parts, AJAX (we're implementing Atlas right now), and the ComponentArt Web.UI suite (http://www.componentart.com)
For unit testing, we're using NUnit and NUnitAsp (slightly modified build to accomodate .Net 2.0 Master Pages).
We're using the Agile development methodolgy; our project management tool is Target Process. We plan 2-week iterations, with a new release every month.
The purpose of this blog is to share our every day findings, tips and tricks, work arounds etc... with the software development community. I hope it'll be useful to some of you.
I am the CTO of the Open Compliance and Ethics group, a non-profit organization whose mission is to integrate corporate governance, risk management and culture. In short we deal with business ethics; our goal is to provide a solid, flexible framework that will prevent future Enron-like collapses.
This blog will not be particularly focused on corporate ethics, but rather on our technolgy research, findings, ideas etc...
After looking thoroughly at different CMS packages (and there are are a lot of really good ones out there), we decided a year ago to develop our own knowledge portal. Why? Well, we use a pretty well-defined and complex data schema to create our guidelines and practices, and couldn 't find an easy way to port our existing data and reports to an off-the-shelf product. Also, because our knowledge portal is both a development tool and a way for members to access content, we needed a very robust aand complex permission system.
Our web site URL is http://www.oceg.org. It's still a work in progress, but we've gone a long way over the past few months.
Here's a quick tech overview:
- Database: SQL Server 2005
- Middleware: C#.Net 2.0
- Front-end; ASP.NET 2.0, themes, web parts, AJAX (we're implementing Atlas right now), and the ComponentArt Web.UI suite (http://www.componentart.com)
For unit testing, we're using NUnit and NUnitAsp (slightly modified build to accomodate .Net 2.0 Master Pages).
We're using the Agile development methodolgy; our project management tool is Target Process. We plan 2-week iterations, with a new release every month.
The purpose of this blog is to share our every day findings, tips and tricks, work arounds etc... with the software development community. I hope it'll be useful to some of you.
Subscribe to:
Posts (Atom)

