Well I suppose that by now we all know that live applications should have this set to false (debug=false)!

But why would we do this?

2 great articles have come up with this answer:

Tess says: “ASP.NET Memory: If your application is in production… then why is debug=true”

and also:

Scott says: “Don’t run production ASP.NET Applications with debug=”true” enabled“

both of these great articles from MS guys (and girls :)) explain the exact reasons why you shouldn’t do this!

This morning while checking my blog-roll I found some great new articles.

It just amazes me how much good info you can find while surfing through blogs:

VB.NET Team - EMEA Tour Followup (with ALLOT of great links): http://blogs.msdn.com/vbteam/archive/2006/04/20/580220.aspx

ScottGu - one of my favorite blogs (this guy always has great posts):

IIS7 *Magic* - http://weblogs.asp.net/scottgu/archive/2006/04/20/443513.aspx
Express products - http://weblogs.asp.net/scottgu/archive/2006/04/20/443461.aspx

Dino Esposito - Customized GridView - http://msdn.microsoft.com/msdnmag/issues/06/05/CuttingEdge/default.aspx


hope you enjoy it…

Recently Microsoft has released 2 new things (amongst others):

1. April CTP of Atlas

As it didn’t work in the previous release, thought I’d try it with this one. Unfortunatly the same result… it doesn’t work. Just hope that the guys from MS are able to make it available before the release of Atlas

2. Atlas Control Toolkit

This is a farely new thing… Microsoft has released a set of control extenders with which you can add some pretty cool functionalities to your controls. You can read more about the control toolkit here.

My goal was for the day to try out the control extenders in DNN (as a part of a DNN module) and see if they work (although many of them utilise UpdatePanel which I saw from previous scenarios doesn’t work quite well yet).

The result of the test was:

One of the most interesting ideas I have seen lately, community credit. Basically they award your efforts in your community with all kinds of geeky prizes.

Their moto is:

“We give stupid prizes to smart people”

I think Ill send a mail to the guy in charge and see how we can combine our community sites with his great idea. Until then you can go over there and sign-up to win prizes:

http://www.community-credit.com

So I’m currently finishing up an improved FileSyncronization routine for DotNetNuke. As in DotNetNuke, information about all files on the file system is stored in the database (not files, only info about them!) the process works in a way that the application retrieves all files from the database in a DataTable and then iterates through files and directories on the file system and compares each file to the records in the data table. Depending on the file in the data table it determines the action to be executed with the file – Create, Update, No Action and later on in the process executes the appropriate action based on the mentioned mark.

Now, I’m doing my tests on 2000+ files in one portal, with simultaneous running of both the scheduled job and the manual synchronization run, which in total runs the synchronization routines for some 4000 times in one test sequence (2000 are synced with the scheduled job and again 2000 manually)

I’ve gotten it almost fast enough for our needs, it does both the manual run and scheduled job run each in some 45 seconds (previously it was some 5 minutes), but greedy as only a human being can be… I wanted it faster! J

So I’ve fired up the profiler and went digging…it turned up that there were 2 hotspots on which I can influence:

1. DataTable.Select – I will leave this for some other post
2. Image.FromFile

So now we get to the point….

As in DotNetNuke along with the file info also the routine checks and saves the info on a potential images (if the file is an image, its height and width are saved along with it’s info) it uses the following code piece to do it:

Dim imgImage As System.Drawing.Image

Try
imgImage = imgImage.FromFile(sourceFilePath)
With imgImage
imageHeight = .Height
imageWidth = .Width
.Dispose()
End With
Catch
contentType = “application/octet-stream”
End Try

When profiled the application I got the following results (on 3 test runs) for the bolded function above:

So I went looking if I could find an alternative for the same functionality, and discovered it in the bitmap:

Dim imgBitmap As Bitmap
Try
imgBitmap = New Bitmap(sourceFilePath, False)
With imgBitmap
imageHeight = .Height
imageWidth = .Width
.Dispose()
End With
Catch
contentType = “application/octet-stream”
End Try

This one worked fine (it gave the same dimensions of the picture, it didn’t brake and such), and gave me the following info when being profiled:

So as you can see, on average the bitmap snip. has shown itself to be some +- 30% faster than the Image.FromFile in this scenario!

UPDATE: I was digging around DNN and found that I was completely wrong… the modules are NOT added at PreRender, they are added through from default.aspx.vb through skin.vb (by calling the right skin) in a function in skin.vb. All this is done at Page_Init, both of Default.aspx and Skin.vb!

So, I’ve talked to the guys at Microsoft… I’ve contacted ScottGu and he was kind enough (thanks Scott) to forward my mail to one of the guys at MS.

The answer I got to my mail was:

“Hi Vladan,

It’s somewhat unlikely that UpdatePanel will support being added as late as PreRender. We might be able to make it a bit later than Init, but probably not much later. There are many reasons for this, including that the controls inside it might not work if they are loaded so late. One thing that we do plan to have is some kind of new interface that custom controls can implement to allow them to have UpdatePanel-like behavior, but we don’t have any details on that just yet.

Is it possible for DotNetNuke to have static UpdatePanels in the page and then dynamically load the UserControls into the panels?

Thanks,
Eilon”

Thanks for the heads up Eilon

I am still thankful to Eilon and Scott for assisting me, I think I will mail them again after I test some more things

ASP.NET team works really hard on getting the most work done for us ASP.NET lovers.

If you don’t know where to follow their progress, it is regularly updated on the ScottGu’s blog.

Probably if you are reading this than you will be happy to know (I know I am) that VS 2005 Web Application project is in it’s release candidate!

Or that in April a whole bunch ASP.NET releases will occur.


So the point of this post being, April is a great month for ASP.NET! And you can read all about it on ScottGu’s blog.

(And no…. this is not a commercial :))

Microsoft decided this year to give me the MVP Award (Most Valuable Professional) in the field of
Visual Developer - ASP/ASP.NET.

You can checkout the site of the award itself; or checkout my profile on their site.

I’m very thankful for the opportunity to do more in my community and expect that this award will help me to get my voice and the voice of my community to be heard louder!

I got a question from a colleague today telling me that when she presses the search button in the Search skinobject she gets an “Object reference not set……” error

when you look at the Event log of that portal the stack trace looks something like:

to avoid (or solve) this problem, you need to have a page in your portal (usually Search results) which has on it the Search Results module.

After you put that module on such a page you need to hit re-index of the search and everything should work ok.

Again one of the things I see asked often.

My answer usually:

“Restarting the process will not help you.

I have the same problem. The problem is that the syncronization functionality is not optimized for high amounts of files, and when you click synchronize the application takes ALL the files from ALL portals, caches that list (my problem came at around 10 000 files on one host), and for each file extracts that list from the cache, deserializes it and creates a new object (well copy) of the one from cache (also a veeeery expensive operation).

All of this works for a small amount of files, but for a large one (like I had on one host) it lasted for me for about 30-40 minutes each time for the host, and for a portal syncronize (for a portal which had 1200 files) it took about 5-6 minutes.”

which is usually followed by another one:

“Well I found it best to do 2 things:

1. Not use the snycronization at all - do everything through file manager (so without FTP)

2. Re-program the syncronization routine - I’ve actually done this, and have cut times on mine 1200 files from 6 minutes to 8-10 seconds of snycronization. The only problem is that it contains one bug to which I haven’t yet had time to give to solve it (some files still remain on the file system and do not end up in the db, I’m not sure that this is my bug, maybe even it’s present in the core syncronization itself) 

hope this helps “

I have pasted this here so that:

a) People googling can find it (I know I’ve spent some time searching the internet)
b) So that I can reference it in my answers to the forums

I see different people asking on DNN forums about CPU being occupied by DNN allot (mostly it spikes to 100%). As I have recently spent some time investigating this I often answer to these questions with something like:

“HI,

We’ve bean also having similar problems (CPU 100%). Mostly it was due to 2 possible reasons (if we can eliminate the server as an issue?!?!)

What is important about these things is that they all still cause problems after improving the performance (well actually execution time) with some standard things (like compression, moving viewstate to the server, improving caching).

So guys you have some real problems:

1. Schedule problems

Poorly programmed scheduled jobs. One good example of this is the FileSyncronization Schedule, if you have allot of files it will very likely spike your server to 100%. I’ve described this problem already on this thread

2. Module problems

Some of the modules are built well, some are not…. also some are configured well, some are not…. to be more concrete, we turned on module caching for DnnBB forum, and with public pages it would just get *stuck* and loop into something until the timeout would brake.

When viewing the application internals with WindowsDebugger at time when the cpu was at 100% I either found only run-away threads with scheduler or DnnBB executing allot of repetitive statements. For DnnBB I got the same result when viewing the SQL database with SQL Profiler.

My immediate cure for the problem was:

1. Turn off file synchronization (it ran every hour, for 40 minutes each time - spiked the server, we had about 10000 files on that host, more info on the mentioned thread above)

2. Turn of module caching for DnnBB (now the forum runs ok)

I’m not sure that these are all of our problems, but with this we solved most of them, and the server is breathing allot easier now!

hope this helps a bit “

I have pasted this here so that:

a) People googling can find it (I know I’ve spent some time searching the internet)
b) So that I can reference it in my answers to the forums

So my module works fine without Atlas now, it adds data, it shows it… it can delete, edit… a bunch of stuff

But, I wanted to add Atlas now.

Basically I had to do 3 things:

1. Make sure I have Atlas dll in my bin directory
2. Add the necessary things to my web.config
3. Add the code for the update panel which will partially render my page

ok, 1 and 2 I did by this instructions

the third looked like this after implementing it:

the red areas are where I’ve put some Atlas code (as in many examples… most famous one beaing this)

but guess what…. It doesn’t work. I’m puzzled now because things were going so great (and I’ve done a similar thing in *normal* asp.net)

the results looks like this:

1. You select a user in the dropdownlist, we send a request for data, and progress indicator (Loading data…) tells us that the Atlas is fetching data

2. But the results ends up not changing

so, now I’m off to investigate the possible problem… The difficulty being here that nothing breaks… and nothing is changed either.

you can download the newly changed files here (just drop them over the old ones, the zip contains only updates)

UPDATE: I found some mention of control loading process sensitivity of Atlas, with DNN this could be the problem because it loads the module in a specific way (It executes it on PreRender event) - I will investigate this further.

I saw a post on the DotNetNuke forums yesterday in which someone asks if they tried to integrate DotNetNuke and Atlas because they weren’t able to make it work.

So this morning I went to take a crack at it (who knows maybe Ill succeed), I’ve installed a new version of DotNetNuke 4.0.3 and Atlas March CTP and decided to do this in 2 steps:

1. Create a .NET 2.0 DNN module in DNN 4.0 (today)
2. Re-paint the module with Atlas functionalities using UpdatePanel 

so let’s start with step 1…..

I made a small module for DotNetNuke based on the starter kit module provided by the core. The module looks like the following:

for a great explanation how to build a DotNetNuke 4.0 module take a look at a great article by Michael article here.

The module allows a user to post some text content to the database by typing some text into the textbox at the bottom.

It currently consists of the following controls:

1. DropdownList - populated by a ObjectDataSource control which fetches from the database all the users (distinct) which have posted some info
2. GridView - also populated by a ObjectDataSource, only it can be filtered by selecting some user from the mentioned dropdown
3. DetailsView - allows you to post some info to the database, in the codebehind to a new record are also added ModuleId and the current user UserId

the module itself is pretty straight forward, and I’ve bean able to build it in half an hour. Additionally by clicking some checkboxes (ehehe… this was easy) I’ve added functionality for inline editing, deleting and such

to illustrate how easy it is here are some more screenshots of the code (complete download will be at the end of the article)

1. Design view of the main control 

2. HTML code of the same view