I have often found that when debugging applications that a lot of time is spent drilling down into the various custom objects to see what the values are of specific instance methods. In this blog posting I will demonstrate the default behavior of Visual Studio when debugging a class, I will then show how you can improve the debugging experience with the addition of a simple attribute.
Read more...
Posted by Mitchel on Friday, July 03, 2009
A very common question that I get asked by people is; what tools do you use to complete your development and what type of system do you use. Now, I believe I have written a bit about this in the past, but I thought I would take some time to go through and give a bit of a detailed overview of what I use for development and why I have selected the hardware and software that I have. I will cover this in detail from both the hardware and software point of view.
Read more...
Posted by Mitchel on Friday, May 22, 2009
My last blog article "Selecting the Right Source Control Provider" touched on the evaluation criteria that I use when looking for a source control system. This article is a review of sorts of SourceGear's Vault product, my preferred source control system. I'll start by reviewing vault as it relates to the criteria from the previous article, I will then provide my overall feedback on my experience with Vault.
Read more...
Posted by Mitchel on Thursday, April 16, 2009
One of the most common questions that I have been getting recently has been "what source control provider do you use and why?". This article is the first in a series of two articles about source control. This article takes a quick look at criteria that I believe is important to consider when it comes to evaulating source control systems for use. The next article in the series will be a review of the source control system that I use, in relation to the evaulation criteria that I list in this article.
Read more...
Posted by Mitchel on Wednesday, April 08, 2009
While working through some issues recently with some legacy code writen by someone else I was faced with a horrible case of a shared object that was writing to the file. This was a "custom" logging implementation and opened a file for append, inserted the line, and then closed the file. Well in times of heavy load the system would encounter errors such as "Cannot access ___ because it is being used by another process". So in effect the file was either still open, or the lock was not yet released. This post goes through a bit of the detail on how I resolved the issue.
Read more...
Posted by Mitchel on Thursday, January 22, 2009
One item that many people find unusual about my DotNetNuke installation guides is my insistance on NOT using the Database.mdf, dynamically attached database file for the creation of a DotNetNuke database. In my tutorials I have quickly dismissed the topic by noting that "issues" come up when trying to use a dynamically attached database and I leave it at this. Well after seeing more questions on this topic recently in the DotNetNuke.com forums I wanted to take a moment to put my $0.02 out there as to WHY I don't like it. I will do this by discussing quickly what the differences are in the two approaches, then I'll discuss the "downfalls" of each.
Differences in Approach
Everyone is most likely familiar with the common process for creating a SQL Server databse, during the creation process two files are added the .mdf which stores the actual data and the .ldf which stoes the log. When the database is created the files are typically placed inside the "Program Files" folder, storing them with the rest of the SQL Server files, although this location can be changed by the Server Administrator.
The dynamic attachment method uses a pre-defined database.mdf file that is located in the App_Data folder of the DotNetNuke installation. When the system connects to the database server this file is attached to the server and operates like a database on the server would normally, however, all data is stored inside the DNN location.
Why I Think Its Bad
One of the most common arguments supporting Dynamically attached databases is that they "save time". Well That might be true for the first connection, however, in my experience the time spent troubleshooting later makes it a much longer process. The first thing to remember is that the database is attached and it has a name associated with it, DotNetNuke when working with DNN, if you go to install a second DotNetNuke installation on the same server with the dynamically attached file an error will appear noting that the database already exists. For beginners this can be a very upsetting experience.
However, the most problematic downfall of dynamically attached databases in my experience is that you must "Attach" the database before you can manipulate it in SQL Server Management Studio or SSMS Express. This is a very common stumbling block as individuals will know that the database exists, however, SSMS will not show the database at all, until it has ben successfully attached.
Overall
I feel that overall there are no compelling reasons that would direct a person to use a dynamically attached database rather than a standard SQL Server database especially when it comes to databases that need to be administered on a regular basis. If working in a test environment it might be helpful to have a dynamically attached database, but that is a limited use case, and for the most part DotNetNuke databases at one point in their life will need to be administered, backed up, restored, or moved. For these actions a standard database is a good way to go.
Please share any comments/feedback below.
Posted by Mitchel on Monday, November 24, 2008
Recently I have been working on creating a dynamic reporting engine for use within the DotNetNuke system, a method to allow for the execution of a stored procedure and the proper display of the results. This includes creating a list of parameters, including dynamically loaded lookup systems and more. Well the most complex item that I have had to condition for was how to deal with filter options that require the use of the SQL IN clause, there are many ways of doing this, but I have found a way that appears to work perfect for my needs, this will be explained in this posting.
Read more...
Posted by Mitchel on Friday, August 08, 2008
Recently I have answered a number of questions regarding an easy way to export datagrid contents to excel format. In this blog post I will share a static class that I have created called "ExportHelper" which I use quite often to generate quick Excel exports of datagrid data. I will outline the process and the code below. It should be noted that this solution is NOT a DotNetNuke specific solution, I use this for both DotNetNuke and standard ASP.NET solutions.
Read more...
Posted by Mitchel on Thursday, May 22, 2008
Recently when browsing the forums on DotNetNuke.com I have noticed more and more
questions regarding Script Injection vulnerability in the core and third-party modules.
I have often found that at times it is hard for non-developers to truly understand
the concept of script injection and what makes a site vulnerable. So in this
article I will take a bit of time to discuss both types of injection that users
of DotNetNuke should be aware of, how to test for them, and also how to prevent
the vulnerability when creating modules.
Read more...
Posted by Mitchel on Tuesday, May 20, 2008
Recently I have been asked by multiple people what rapid design tools I use, or
what types of code generation tools do I use. Many people are surprised when
I tell them that for the most part I don't use any rapid generation tools.
I do use a few home grown tools, such as my Info Class Generator, which is available
on this site. However, that is as far as I go with automated code generators.
However, one thing that I have started using more and more frequently are Code Snippets
within Visual Studio.
I have found that creating a few helpful Code Snippets has allowed me to quickly
and easily format my code, and build my needed structures in almost no time.
In this blog article I will share two of my most commonly used Code Snippets, if
there is a demand I will post future code snippets here as well.
Read more...
Posted by Mitchel on Sunday, March 02, 2008
Previous Page
1 of 2
Next Page