The 'My' Namespace in a VB.NET Application is Missing Members

OK I ran across this little snag in a VB.NET application, and thought I might share an easy solution to the problem. If you ever have a .NET solution that originated in a previous version other than 2010 and has been upgraded, you might have some difficulty accessing members of the 'My' namespace. Specifically I was missing the auto generated 'MyWebExtensions.vb' code file displayed below:


This resulted in the "'Application' is not a member of 'My'" error:


There are probably a few tricks you could make to the solution (.sln) file by opening it in Notepad and fixing the appropriate settings, but the easiest way to fix the error is to remove the 'My' extension and add it back into the project. To do this open the project's properties of the project where the error is occurring, and click on the "My Extensions" tab.


The 'My' extension you need for your project is dependent on the type of project you have created (Web, WPF, etc.), so make sure to select the proper one when re-adding. First though, right-click the current extension already added and select “Remove Extension”


Then press the "Add Extension" button in the bottom right-hand corner, and add the appropriate extension back into your project. This should auto-generate the 'MyWebExtensions.vb' code file and fix any previously non-accessible members in the 'My' namespace.


For more information on the 'My' namespace, check out the (2) MSDN links below:

My Namespace

How My Depends on Project Type (Visual Basic)

Honored to Receive the "Microsoft Community Contributor Award"

I received a wonderful email today that I have been recognized with the 2011 "Microsoft Community Contributor Award"! This entry is not to toot my own horn, but rather to say thank you to Microsoft for the recognition. I have used Microsoft products and software almost my entire life, and now am very proud to make my career and hobby in software engineering revolve around Microsoft and the .NET Framework technologies. As I continue to hone and grow my own skills, I will continue to share and contribute that knowledge to help others in our community in whatever way I can. It might be a small token of recognition, but one that I am proud and happy about. Thank you Microsoft.

ASP.NET Web Forms vs. ASP.NET MVC

So it has been a few years now since Microsoft introduced the ASP.NET MVC Framework which is Microsoft's implementation of the MVC Architecture for ASP.NET. No the MVC (Model-View-Controller) architecture is not a new concept; just Microsoft's implementation of it in the .NET Framework. There has been a lot of buzz around whether to continue to use ASP.NET web forms which have been around since 2001, or to go with this "hot" new technology in ASP.NET MVC... or something else! There is no 'Silver-Bullet' answer to this, and with most situations, 'it depends'.

Oh I know, you might have "Googled" the exact phrase of this blog post and were hoping to get some answer to exactly which one is better. Nope. I just want to highlight a few of the strengths and weaknesses of both from an abstract point of view, and briefly mention some other alternatives too.

To begin, I am going to repeat a stat that Andrew Duthie (Twitter handle: @devhammer) brought up on this topic at an ASP.NET Firestarter event in Orlando last December. He showed a stat that somewhere in the range of 80%+ dev shops were still using ASP.NET web forms for their bread and butter applications, and that ASP.NET web forms were not going away! Anyone trying to spread a rumor like that needs to check with the folks direct from Redmond 1st, because it simply isn't true. To this end, folks shouldn't feel like they missed the last train to MVC euphoria because everyone hasn't boarded yet. I am not building up an article against MVC; I just want to point out that it is a misnomer that ASP.NET MVC has completely replaced an outdated web forms architecture that some may speak convincingly of on forums and blogs.

So maybe you are leading a team of developers and are looking to decide the pros and cons of MVC, or maybe you are about to build a site for a friend/family member as fast as possible, or involved in a large scale enterprise application that will be web based. Whatever the scenario, you want to know the details of which architecture to choose. After all it will be quite difficult to change between the two once the code begins to flow. Making the right decision up front is important in any of these scenarios no matter how small or large the project.

Let's 1st speak to the advantages of the MVC framework. 1st and foremost in my book is the Architecture itself: M-V-C. It is going to be tough to break this model and rearrange how the application is built. Having your or your team's hand forced into a stable and mature architecture like MVC is a good thing. Raise your hand (like anyone can see...) if you have ever seen or maybe written one of those spaghetti sandwich ASP.NET web forms application that has raw SQL right behind "btnSave_Click()". Blah! Awful nasty, all code-behind the forms, non-scalable mess of an application. So 'point' to MVC for guiding developers to a decent architecture. You can adhere to several good architectures using ASP.NET, but it is up to the developer or team of developers to be disciplined enough to stick to the architecture and not lay back on a fat UI layer. Separation of concerns is a key Object Oriented Concept and a real winner for the MVC architecture. Each layer has its own responsibility, and placing the proper code in its responsible layer will make for a much better code base to scale, maintain, inherit, etc.

Next ASP.NET MVC allows the developer to have "Full Control" over the rendered HTML. For now I am going to leave this as an advantage for MVC, but caution that not everyone fully understands what this means, and it might not be advantageous for a vast majority of applications not needing this type of control. Let me elaborate a bit; that wonderful winter of 2001 when many of our lives took a turn for the better as Scott Guthrie (Twitter handle: @scottgu) came up with what is ASP.NET web forms, and decided while sipping hot cocoa that if you drug a label onto a web form, it would get rendered as a DIV tag. He made this decision (or Microsoft) and not you. You pick the ASP.NET server controls you want to drag onto a web form, but don't have control over what HTML elements actually get rendered on the client as a result. You just know that when a Gridview is dragged onto a form, it will be displayed on the client. You don't know (or need to in many situations) that it might be a series of DIVs and Input HTML controls. This abstraction is actually an advantage for ASP.NET web forms. For many web applications built, we have relied on this drag and drop capability, and trusted the final output that will be rendered to ASP.NET. However, if you have ever found the way the ASP.NET sever controls get rendered is not exactly how you want or need it, then MVC is a better choice as it will allow you to have control over the final rendering. If you do not have any main issues with how ASP.NET web form server controls get rendered in your applications, then this might not be an "advantage" that you can sell to your tech manager or team when trying to build the next project using MVC.

Another advantage of using ASP.NET MVC that ties back into the individual layers is testability, specifically unit testing. Because the application is loosely coupled with code in its separate layers, the ability to create unit tests increases greatly. The event based ASP.NET pages that rely on things like Session, Context, Response, etc are quite difficult to effectively test because of the inability to isolate specific page functionality due to its nature of being spread out and external dependencies as well. MVC improves on this greatly, and is architected to be testable. 'Point' MVC.

So let's examine ASP.NET web forms for a minute. As I mentioned they were born sometime in late 2001, so maturity and a rich tool set (both from Microsoft and 3rd party) is a big advantage. These "tools", or ASP.NET server controls make up a style of development referred to often when speaking of ASP.NET web forms called RAD or Rapid Application Development. "Hey I can drag a few ASP.NET text boxes, some labels, this Gridview thingy, press publish, and WHAT??!! I have a website!" Now that website might be junk, but hey its done already. On to the next project, right? Well not quite. 'Fast', especially in our field doesn't mean better. That site might be done, but as eluded to prior, its design is junk and it will not maintain or scale well. But what if you know the scope is a single, simple page? Well then a tool like web forms is probably perfect, and MVC might be overkill if speed of development is of the essence. Don't be fooled, web forms + data binding, etc. will be faster to generate just based on the drag-and-drop + wizardry capabilities. Just don't have a code review and everything will be fine! So the RAD capabilities of ASP.NET web forms can be a double edged sword. A quality ASP.NET web forms with a pre-determined architecture (3-layer, Domain Driven Design, MVP, etc.) that uses developers with discipline to adhere to it, is a much better choice when creating ASP.NET web form applications.

Along these lines is another advantage with web forms and that is 'Experience'; specifically in relation to a developer's experience with the technology. Again with web forms being a mature technology going on 10 years, there is a solid developer core with ample experience. If you are leading a team of 8-10 developers, you are the only one with MVC experience, and everyone else knows web forms, then this needs to play into your decision of which technology to use. Are you prepared to take the financial impact of formal MVC training through remote seminars, current books, or on-sight training? Can you afford the 1-3 month setback while the team gets up to speed on ASP.NET MVC to say a beginner/intermediate level? If these are not an issue, and the advantages of ASP.NET MVC mentioned previously are present, then it may be the better choice regardless of the upfront cost in time, money, etc. If however, you need to begin writing code immediately with a team of web form rich experience developers and are under a tight deadline, then maybe holding off on using MVC is the better decision. In the end you need to weigh the factors to make the best decision.

There are some other disadvantages to the web forms technology that I will mention briefly here as well. The web form's postback model uses client side generated '_doPostBack()' events for each server callback. If JavaScript is disabled this will cause several problems for the web forms application. It is also difficult to manipulate manually if writing your own client side scripts. MVC improves on this using REST based URLs. The next disadvantage with web forms is ViewState. Referring back to my comments about poorly designed web form applications, a bloated ViewState can cause pages to be larger and slower than they need to be. ViewState stores a base64 encoded string with information about controls state to persist postbacks and to help combat the stateless nature of the web. This however becomes a disadvantage for web forms when abused.

Now let's throw a cog into the wheel and add in another choice for web development in the .NET realm: Silverlight. Oh yeah, and honestly my favorite when it comes to rich UI content. However, you still need a hosting application and Silverlight can be integrated into either ASP.NET web forms or ASP.NET MVC applications. And I don't want to confuse anyone either because Silverlight is not an entire 'web' Framework onto its own and only works alone as individual controls. The Silverlight controls integrate into a web forms or MVC application as just another control and can co-exist with controls of either technology. However, since Silverlight can't invoke the controller class in MVC, or directly postback to the server when using web forms, you will need to use services (WCF) to accomplish this task. Anyone using Silverlight previously knows that WCF services can bridge the gap between the Silverlight control and the server.

Decisions, decisions, which technology to pick? There is a lot to weigh when it comes to these two technologies: ASP.NET web forms or ASP.NET MVC. Are you trying to draw a line in the sand and say, "Only MVC web apps from here on out!!" Personally I would not do that, because it wasn't like 10 years ago when we moved from classic ASP to ASP.NET and were able to be that bold. Now ASP.NET MVC has to be looked at as another tool (a very powerful and cool one) in the proverbial toolbox. There will be a time when MVC is the proper decision, and a time when web forms is the proper one. I strongly urge those picking web forms to at a minimum not fall into the trap of bad or poorly architected code, and be disciplined to use an architecture that is more scalable and maintainable (check my review of the book Professional ASP.NET Design Patterns). And lastly and maybe most importantly, be a 'realist' and not a 'purist' when making this decision. Do what is best and right, and not just which one theoretically is better in argument. This will help you decide. Either way its great to be a .NET developer with such a plethora of technologies to choose from.

How To: Encode a JavaScript string in .NET To Escape Characters (i.e. Single Quotes) Automatically

There is a handy new Utility method new to the .NET Framework 4.0 found in the System.Web.HttpUtility namepsace called HttpUtility.JavaScriptStringEncode. It allows you the developer to create any string needed and URL encodes it to be usable by JavaScript.

Ever tried making a Utility method to create a script to be registered with the page in ASP.NET that will popup a JS alert box and takes a message? Ever see what happens when you try and place a single quote in the value like "The value 'x' is not allowed"? The JS will error out on the page with a " Expected ')' " type error message. If you use the utility mentioned above, the encoding is done for you and injects any needed escape characters. The line of code below shows how this might be done in .NET code:

Dim Message As String = "The value 'x' is not allowed"
'URL Encode the message prior to registering with the page
Dim JsAlert As String = "alert('""" & HttpUtility.JavaScriptStringEncode(Message) & """');"
ClientScript.RegisterStartupScript(Page.GetType(), "AlertJsFunction", JsAlert)

Visual Studio Live! is coming up soon (April 18-22) in Las Vegas

If you’ve never been to Visual Studio Live, it offers developers, programmers, software engineers and architects an unbiased blend of practical and immediately-applicable training in Visual Studio, Silverlight, WPF, .NET and more. Plus, there will be 2 new tracks on mobile development and HTML5 this year! Check out the Visual Studio Live! Agenda at http://bit.ly/VSLiveTrks.

Legacy SourceSafe: How To Find Checked Out Files By User

If you still happen to be using Microsoft SourceSafe, stop and use Team Foundation Server ;) No all kidding aside, you may still use VSS or be ready to migrate to a newer platform like TFS and need to do some cleanup or preparation first. One common task is to find out all of the files checked out by an individual user.

You can accomplish this using the SS.exe tool that is installed alongside SourceSafe. It is located in the following directory:

C:\Program Files\Microsoft Visual Studio\VSS\win32

To open the tool, open a command prompt (I used Visual Studio .NET's Command Line Tool) and change directories to the location of SS.exe like below (if your files do truly exist on the C:\ drive):

CD C:\Program Files\Microsoft Visual Studio\VSS\win32

Now you are ready to issue commands to the SS.exe tool. You might wonder why you can’t just open it directly, but if you try only the screen flashes and the VSS help for the tool is opened. You must run commands against the tool in an existing command window session.

The command to fins all checked out files in VSS by user is as follows:

ss.exe Status $/ -R -U <username>

The 'Status' command extracts checked out file information, the '-R' switch dictates the search will be recursive to subprojects, and the "-U" switch specifies a user name. So if we had a username "jsmith" we could update the command to be more specific as follows:

ss.exe Status $/ -R -U jsmith

Upon pressing enter, please be patient. The search process can take quite some time, especially if there are a lot of files in VSS. The result set will show the project and files checked out by the user specified. If needed, you can copy all of the results into notepad, by right-clicking on the window title, and selecting Edit -> Select All ...and then Edit -> Copy.

For more detailed information on the SS.exe command tool and its Command Options, please check out the links below:

MSDN: Command Options

MSDN: SS Utility

Workaround For VS.NET ASP.NET Design Tab Not Rendering Controls

As of recent, most all of the projects I have been working on are in VS.NET 2010 using .NET Framework 4.0, and several are upgrades from .NET Framework 3.5 VS.NET 2008 solutions. I rarely use the 'Designer' tab to preview the generated controls of my ASP.NET pages, but in some instances I want to see the wizard of a control for configuration (i.e. Object Data Source Control). Not that there isn't code I couldn't just create by hand, but sometimes it is faster to have the code auto-generated for me. In this case I needed to have the control render in Design view.

On this note I will say I am not a big fan of the 'Design' tab to view auto-generated pages. I do not believe VS.NET uses the same rendering engine to show the auto-generated pages as is when the page is rendered in IIS. Therefore early on I found inconsistencies and nuances that showed visual differences between the two (design and run time), so I all but abandoned using the IDE 'Design' view. In fact I think one becomes a more proficient ASP.NET and web developer in general when you can begin to visualize the web pages during coding without needing a 'picture' to see after every line of code is written. Then run the page either in either the local dev server through VS.NET or in IIS to have it render properly, and then use any of the following to break down a page when needed: IE Developer Tools (IE), FireBug Lite (IE or FireFox), Chrome Developer Tools (Chrome).

Back to the problem at hand - I noticed that ALL of my pages (content pages of a single simple Master page) show the message "response is not available in this context" for all of my controls when accessing via the design view. I had tried deleting the page from my project, adding a new page, and copying back in the source and code; same error. I also tried cutting out controls 1 at a time, and clicking "Refresh" in the designer but that was not working either. Clearing all cached pages in the Temporary ASP.NET directories did fix the problem either.

Having all of my pages with the same issue, helped direct me to a class that all pages were inheriting from. In this class there is a method to Override the OnInit() method to run some common functionality. Within this method there was code to set properties on the HttpResponse object. Therein lies the problem. Making calls to manipulate the HttpResponse object and getting the error message: "response is not available in this context".

The fix is simple and straight forward. One way would be just to comment out the code, but this has its downside with no explanation needed. I wanted something more maintenance free. There was a better solution: if there is NO HttpContext avalaible, then do not attempt to access it, or the HttpResponse object. While in the VS.NET IDE and viewing the 'Design' tab, it makes sense that the HttpContext is not available and therefore any related code should be skipped.

 'Do not attempt to access the HttpContext if it does not exist (i.e. in Design mode of IDE)
 If HttpContext.Current IsNot Nothing Then
   'Do not cache the web page        
    Response.CacheControl = "no-cache"
 End If

One interesting thing I found in researching this issue was that cleaning the solution (which clears the \bin of all compiled code) and then viewing the page in the 'Design' tab with the above Response code only (no "If HttpContext.Current IsNot Nothing"), the page would display. As soon as I built the solution, and did not have the workaround above, I would go back to receiving the "response is not available in this context" error. So the IDE must be rendering the page differently based on if it has been compiled or not already, and possibly only showing the rendered page strictly on HTML and not on any precompiled code-behind in this situation. This is lower level details of the VS.NET IDE that I am unsure about. The main point here is to use the logic in the code example above to be more explicit about when that code will be ran, and when it will be skipped.