Friday, October 23, 2009
Where does my blog title come from?
In case you are wondering about the odd title of my blog it is a little inside joke. In addition to being an old school software developer I'm also an old school gamer. The reference is best described here: All your base are belong to us. It's just a simple play on words built on an old poorly translated game dialog.
Using the ResolveUrl method inside your class library Business Logic Layer (BLL)
Getting around passing HttpContext.Current to your business logic layer, or BLL.
The Problem:
You want to use handy methods like ResolveUrl inside your Business Logic Layer (BLL) which is a class library. You don't want to reference System.Web or any .Net framework library beneath the System.Web subsystem inside your BLL libraries.
The Fix:
Create a small Utility class inside your class library and pass it a delegate. I know, I'm not a big fan of Utility (or similar) classes but sometimes you need a little tool-belt class for miscellaneous utilitarian methods. I actually have a Common class library that has even less dependencies than my typical BLL library which is where I stuck this class. Obviously, place the code where appropriate for your solution.
Here we've elegantly passed a generic delegate to our Utility class that will reference back to the provided ResolveUrl method. The method stamp deals with primitive types only (strings) so we have no dependencies passing this function pointer across the domains.
The Why:
You do not want to have a BLL or similar class library system utilizing System.Web, or System.Windows.Forms for that matter. If you have a solution with a web service, a web site and a common class library (BLL or other) and you start using methods dependent on HttpContext.Current you are going to run into issues as this context is not the same between the web service and your web site. A common scenario might be a LINQ2SQL Business Object Layer on top of your SQL Database which has effectively become your BLL. You may have classes that need to store virtual, resolved paths into the database but you want to place the resolving of the URL inside your business object classes to enforce a strong encapsulation of the class. Here's an easy, 5 minute way to provide such features to your business objects without breaking your nTier application model. Now you can happily store the AvatarUrl of your users in the database and have your aspnet_User class do the resolution on the fly!
The Problem:
You want to use handy methods like ResolveUrl inside your Business Logic Layer (BLL) which is a class library. You don't want to reference System.Web or any .Net framework library beneath the System.Web subsystem inside your BLL libraries.
The Fix:
Create a small Utility class inside your class library and pass it a delegate. I know, I'm not a big fan of Utility (or similar) classes but sometimes you need a little tool-belt class for miscellaneous utilitarian methods. I actually have a Common class library that has even less dependencies than my typical BLL library which is where I stuck this class. Obviously, place the code where appropriate for your solution.
using System; namespace Common { public static class Utility { public static Func<string, string> ResolveUrl; } }Now in your global.asax place the following.
private void Session_Start(object sender, EventArgs e) { AssignBusinessLogicLayerHelpers(); } private static void AssignBusinessLogicLayerHelpers() { var context = HttpContext.Current; if (context == null) return; var page = context.Handler as Page; if (page == null) return; // assign the resolve url method if (Utility.ResolveUrl == null) { Utility.ResolveUrl = page.ResolveUrl; } // assign other helper methods here... }
Here we've elegantly passed a generic delegate to our Utility class that will reference back to the provided ResolveUrl method. The method stamp deals with primitive types only (strings) so we have no dependencies passing this function pointer across the domains.
The Why:
You do not want to have a BLL or similar class library system utilizing System.Web, or System.Windows.Forms for that matter. If you have a solution with a web service, a web site and a common class library (BLL or other) and you start using methods dependent on HttpContext.Current you are going to run into issues as this context is not the same between the web service and your web site. A common scenario might be a LINQ2SQL Business Object Layer on top of your SQL Database which has effectively become your BLL. You may have classes that need to store virtual, resolved paths into the database but you want to place the resolving of the URL inside your business object classes to enforce a strong encapsulation of the class. Here's an easy, 5 minute way to provide such features to your business objects without breaking your nTier application model. Now you can happily store the AvatarUrl of your users in the database and have your aspnet_User class do the resolution on the fly!
Saturday, October 17, 2009
FIXED: Windows could not start the Subversion Apache on Local Computer
The Error:
The Fix:
Open the file C:\Program Files\CollabNet\Subversion Server\httpd\conf in notepad. If you installed to a different directory or you're not installing Apache via/ CollabNet navigate to [Root of Apache Install]\httpd\conf and open in Notepad.
find the following lines near the top of the file.
Change the red line to a port number you're not using. If you don't know one, pick an oddball and change until it works.
The Why:
I ran into this error while installing the Apache 2.2 server on my local Windows Vista Machine during the CollabNet Subversion install process. The error reared its ugly head when I tried to actually run the Apache service that was installed. The problem, which I'll freely admit, is I've installed so many software applications for Windows I am prone to accept the default install settings and fix things later if need be. Obviously, when you're trying to port the Apache server to Windows a little more care may be needed than when you're installing a simple Windows application. This little issue popped up because I accepted the default value of Port 80 to use with the Apache server. Oops. Needless to say, as an Asp.Net developer I already have that port in use.
The Event Logs provided the real information I needed to solve the issue.
Error in System Log:
The CollabNet Subversion Apache service terminated with service-specific error 1 (0x1).
Information in System Log:
The CollabNet Subversion Apache service entered the stopped state.
Error in the Application Log:
The Apache service named reported the following error:
>>> (OS 10013)An attempt was made to access a socket in a way forbidden by its access permissions. : make_sock: could not bind to address 0.0.0.0:80
Eureka! Yes, that would cause a problem. It's times like these when I'd like to perform some aerodynamics testing on my laptop...
.
Windows could not start the CollabNet Subversion Apache on Local
Computer. For more information, review the System Event Log. If this is
a non-Microsoft service, contact the service vendor, and refer to
service-specific error code 1.
The Fix:
Open the file C:\Program Files\CollabNet\Subversion Server\httpd\conf in notepad. If you installed to a different directory or you're not installing Apache via/ CollabNet navigate to [Root of Apache Install]\httpd\conf and open in Notepad.
find the following lines near the top of the file.
#
# Listen: Allows you to bind Apache to specific IP addresses and/or
# ports, instead of the default. See also the
# directive.
#
# Change this to Listen on specific IP addresses as shown below to
# prevent Apache from glomming onto all bound IP addresses (0.0.0.0)
#
#Listen 12.34.56.78:80
Listen 80
# directive.
#
# Change this to Listen on specific IP addresses as shown below to
# prevent Apache from glomming onto all bound IP addresses (0.0.0.0)
#
#Listen 12.34.56.78:80
Listen 80
Change the red line to a port number you're not using. If you don't know one, pick an oddball and change until it works.
#Listen 12.34.56.78:80 (this is a comment, leave it alone)
Listen 31337
The Why:
I ran into this error while installing the Apache 2.2 server on my local Windows Vista Machine during the CollabNet Subversion install process. The error reared its ugly head when I tried to actually run the Apache service that was installed. The problem, which I'll freely admit, is I've installed so many software applications for Windows I am prone to accept the default install settings and fix things later if need be. Obviously, when you're trying to port the Apache server to Windows a little more care may be needed than when you're installing a simple Windows application. This little issue popped up because I accepted the default value of Port 80 to use with the Apache server. Oops. Needless to say, as an Asp.Net developer I already have that port in use.
The Event Logs provided the real information I needed to solve the issue.
Error in System Log:
The CollabNet Subversion Apache service terminated with service-specific error 1 (0x1).
Information in System Log:
The CollabNet Subversion Apache service entered the stopped state.
Error in the Application Log:
The Apache service named reported the following error:
>>> (OS 10013)An attempt was made to access a socket in a way forbidden by its access permissions. : make_sock: could not bind to address 0.0.0.0:80
Eureka! Yes, that would cause a problem. It's times like these when I'd like to perform some aerodynamics testing on my laptop...
.
Software Developer Browser and Plugin Choices
Firefox
I do a lot of Asp.Net development and I use Firefox as part of my development toolkit when diagnosing performance and design issues with any website I'm working on. I'm not going to touch on various methods of developing a website as I feel that's akin to trying to change someone's religion. Most of the tools I use however are software development platform choice independent.
Firefox really shines as a development tool when you start utilizing some of the powerful developer-minded plug-ins that are available. I'm going to take the long view of some of these plug-ins in this post then drill down into some of the various features of some of the more comprehensive tools in future posts.
Yahoo! YSlow: I love it when powerhouses like Google, Yahoo, and Microsoft give back to the developer community by providing some free and useful tools. YSlow is a monster albeit a well designed one in that it's features aren't invoked until you ask for them thus keeping your average browsing experience relatively quick. This tool is indispensable for analyzing website speed bottlenecks and consequently design (layout) issues. Yahoo's YSlow relies on another must-have tool Firebug. Again, I will go into much greater detail about these tools soon but if you're not currently using them I highly recommend checking them out. They will make your website development a brighter world and neither are specific to Asp.Net.
Skynet's HTML Validator: Even if you're not a standards compliant centric developer (shame on you) this tool is invaluable. There have been countless times I've run into a layout or design flaw that I couldn't figure out even with FireBug. Sometimes the issue is, quite simply, that I have an artifact in my outgoing XHTML that is propogating down the DOM model to create very undesired results. The HTML Validator is a great tool for catching these flubs.
If you are a standards minded developer and strive to add the...
(or similar compliance) logo to your website then this tool offers huge time saving by bring the validation service to your local machine via Firefox.
Colorzilla: This is a handy tool for fetching HTML color codes in various formats. Although not a power tool in terms of performance analysis I couldn't live without this tool and use it daily.
LiveHttpHeaders: When I need information on what is being posted/received in the HTTP headers this is where I go.
IE Tab: Although I do my personal browsing and development testing in Firefox my target audience is typically an Internet Explorer browsing crowd. This tool is great for switching your gecko rendering engine over to IE to take a look at what the customer will see. I'd rather not load up IE 8 just to take a look at each web page I've designed to make sure it looks the same as my Firefox page, this is how. Also, if you've ever been to an ActiveX dependent web page, having filled in form information only to get stopped because the page requires IE, this is a great way to switch over, refresh the page and not lose everything you've typed in up to that point.
FireShot: I use this extensively for documentation provided to clients of the websites I'm working on. The ability to grab complete screen-shots of a web page, not just the portion visible on the screen/browser, is invaluable. It also provides powerful annotation/editing tools to make documentation simple and easy.
ShowIP: A nice quick tool that keeps me from having to dig up the IP Address of the server I'm working on.
Extended Statusbar: This is a useful one-stop shop for page download and render times.
Clear Cache Button: O.K., not really a developer tool but install it and try living without it. Often I need to clear the browser cache to ensure I'm looking at my last minute development changes.
Google Chrome: While Firefox will probably always remain my workhorse for development testing and debugging sometimes I need a light-weight browser just to take a quick test run through some code changes. Please note: Firefox is a very lightweight browser until you load a ton of plug-ins into it. As a contract software and web developer I do a lot of work on laptops when I'm not at home. When I'm working on a less than hardy development workstation such as a laptop I'll use a default, no frills, install of Chrome to view and test website changes with. It carries a much lighter footprint than Internet Explorer of course, while also providing me with glaring design flaws under the WebKit rendering engine. The WebKit rendering engine is also used by Safari so if you don't have a Mac lying around somewhere this is a simple and easy way to get a look at what your Mac based audience is typically seeing. Please note that Chrome and Safari do not run parallel compliance to the WebKit versions so Chrome is not a replacement to Safari targeted development. So, until Firefox (or a plug-in) makes profile switching a breeze, allowing me to mindlessly run a stripped down version or bloated version of Firefox with ease I will continue to have a place for Chrome in my toolkit.
That's all for now. Soon I will do a much more detailed write up of FireBug and YSlow.
I do a lot of Asp.Net development and I use Firefox as part of my development toolkit when diagnosing performance and design issues with any website I'm working on. I'm not going to touch on various methods of developing a website as I feel that's akin to trying to change someone's religion. Most of the tools I use however are software development platform choice independent.
Firefox really shines as a development tool when you start utilizing some of the powerful developer-minded plug-ins that are available. I'm going to take the long view of some of these plug-ins in this post then drill down into some of the various features of some of the more comprehensive tools in future posts.
Yahoo! YSlow: I love it when powerhouses like Google, Yahoo, and Microsoft give back to the developer community by providing some free and useful tools. YSlow is a monster albeit a well designed one in that it's features aren't invoked until you ask for them thus keeping your average browsing experience relatively quick. This tool is indispensable for analyzing website speed bottlenecks and consequently design (layout) issues. Yahoo's YSlow relies on another must-have tool Firebug. Again, I will go into much greater detail about these tools soon but if you're not currently using them I highly recommend checking them out. They will make your website development a brighter world and neither are specific to Asp.Net.
Skynet's HTML Validator: Even if you're not a standards compliant centric developer (shame on you) this tool is invaluable. There have been countless times I've run into a layout or design flaw that I couldn't figure out even with FireBug. Sometimes the issue is, quite simply, that I have an artifact in my outgoing XHTML that is propogating down the DOM model to create very undesired results. The HTML Validator is a great tool for catching these flubs.
If you are a standards minded developer and strive to add the...
(or similar compliance) logo to your website then this tool offers huge time saving by bring the validation service to your local machine via Firefox.
Colorzilla: This is a handy tool for fetching HTML color codes in various formats. Although not a power tool in terms of performance analysis I couldn't live without this tool and use it daily.
LiveHttpHeaders: When I need information on what is being posted/received in the HTTP headers this is where I go.
IE Tab: Although I do my personal browsing and development testing in Firefox my target audience is typically an Internet Explorer browsing crowd. This tool is great for switching your gecko rendering engine over to IE to take a look at what the customer will see. I'd rather not load up IE 8 just to take a look at each web page I've designed to make sure it looks the same as my Firefox page, this is how. Also, if you've ever been to an ActiveX dependent web page, having filled in form information only to get stopped because the page requires IE, this is a great way to switch over, refresh the page and not lose everything you've typed in up to that point.
FireShot: I use this extensively for documentation provided to clients of the websites I'm working on. The ability to grab complete screen-shots of a web page, not just the portion visible on the screen/browser, is invaluable. It also provides powerful annotation/editing tools to make documentation simple and easy.
ShowIP: A nice quick tool that keeps me from having to dig up the IP Address of the server I'm working on.
Extended Statusbar: This is a useful one-stop shop for page download and render times.
Clear Cache Button: O.K., not really a developer tool but install it and try living without it. Often I need to clear the browser cache to ensure I'm looking at my last minute development changes.
Google Chrome: While Firefox will probably always remain my workhorse for development testing and debugging sometimes I need a light-weight browser just to take a quick test run through some code changes. Please note: Firefox is a very lightweight browser until you load a ton of plug-ins into it. As a contract software and web developer I do a lot of work on laptops when I'm not at home. When I'm working on a less than hardy development workstation such as a laptop I'll use a default, no frills, install of Chrome to view and test website changes with. It carries a much lighter footprint than Internet Explorer of course, while also providing me with glaring design flaws under the WebKit rendering engine. The WebKit rendering engine is also used by Safari so if you don't have a Mac lying around somewhere this is a simple and easy way to get a look at what your Mac based audience is typically seeing. Please note that Chrome and Safari do not run parallel compliance to the WebKit versions so Chrome is not a replacement to Safari targeted development. So, until Firefox (or a plug-in) makes profile switching a breeze, allowing me to mindlessly run a stripped down version or bloated version of Firefox with ease I will continue to have a place for Chrome in my toolkit.
That's all for now. Soon I will do a much more detailed write up of FireBug and YSlow.
Sunday, October 4, 2009
FIXED - Cannot eliminate warning VSP2013 when Code Coverage is enabled in TeamBuild builds
Code coverage instrumentation warning while processing file [Your Assembly]
Warning VSP2013 : Instrumenting this image requires it to run as a 32-bit process. The CLR header flags have been updated to reflect this.
This is something I ran into while writing unit tests for a project. The error pops up when you have code coverage enabled for your unit tests.
Workaround:
1) Open the project properties of the assembly you are instrumenting.
2) Go to the Build tab.
3) Make sure the combo configuration selection is set to the Debug (or equivalent) configuration.
4) Set the "Platform target" to x86.
Note: This sets the assembly to be compiled specifically as 32 bit but only the debug assembly so you do not alter the output of your production, deployment assembly.
This will remove the warning when you are performing code coverage on the debug version of your assembly.
Warning VSP2013 : Instrumenting this image requires it to run as a 32-bit process. The CLR header flags have been updated to reflect this.
This is something I ran into while writing unit tests for a project. The error pops up when you have code coverage enabled for your unit tests.
Workaround:
1) Open the project properties of the assembly you are instrumenting.
2) Go to the Build tab.
3) Make sure the combo configuration selection is set to the Debug (or equivalent) configuration.
4) Set the "Platform target" to x86.
Note: This sets the assembly to be compiled specifically as 32 bit but only the debug assembly so you do not alter the output of your production, deployment assembly.
This will remove the warning when you are performing code coverage on the debug version of your assembly.
Subscribe to:
Posts (Atom)