Which Version of TypeScript is Installed and Which Version is Visual Studio Using?

My rating of TypeScript on a scale of 1-10... a solid 10. 

My rating of finding out which version of TypeScript is installed and being used currently... a 2. 

Sometimes the simplest of things are missed and I think this is one of the cases. There is a lot of playing detective and resulting confusion that will come about trying to figure out which versions of TypeScript are actually installed and subsequently, which is targeted for VS.NET to compile against. I'm here to clear up this confusion and shed some light on this for TypeScript users.

The TypeScript compiler (tsc.exe) is installed through the installation of VS.NET 2013 Update 2 (or later versions), VS.NET 2015, or via the TypeScript tools extensions available through the VisualStudio Gallery. VS.NET users of one of the aforementioned versions are in a good place because TypeScript having been created by Microsoft integrates well into VS.NET. Regardless of installation method, the tooling and compilers are available at the following location:

C:\Program Files (x86)\Microsoft SDKs\TypeScript

As can be seen from the screenshot below, I have folders for versions 1.0 and 1.5:

Now before moving further, the way you've probably found to find out which version of TypeScript is installed is to send the -v option to the compiler which will "Print the compiler's version." You can do this from any location using the command prompt. Doing so on a default installation of say VS.NET 2013 with the 1.0 SDK folder present will yield the following:

Notice we have a SDK folder for version 1.0 however the compiler version is 1.0.3.0. This is because what really matters is not the folder, but rather the actual version of the compiler within the folder. In this case the 1.0 folder contains version 1.3 of the TypeScript compiler.

As mentioned, you can run the -v option against the compiler from anywhere. If you run this command against the directory that physically contains the TypeScript compiler (tsc.exe), then the resulting version output will be that of the compiler in the SDK directory targeted.

Running the version command against the 1.0 directory:

Running the version command against the 1.5 directory:

OK great, we can run version commands in different spots and find out about versions of the compiler. However which one are VS.NET and my project using, and where is that compiler version coming from when I run the -v option in a non-TypeScript SDK directory?

Let's address the global version question 1st. You can run the where tsc command from any command line which will tell you the TypeScript compiler location the version is returned from using the version option:

OK so I have SDK tools version 1.0 (compiler version 1.3 as we know) and 1.5 installed. Why is it returning only the tsc.exe information from the 1.0 SDK folder? It turns out that this information is actually a part of the PATH environmental variable in Windows. There is no magic or real installation assessment going on here. It simply reads the directory value embedded within the path variable for TypeScript and finds the tsc.exe version within that specified directory. Here is what was within my Windows PATH variable for TypeScript:

C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0\

Before we get much further it turns out all these versioning commands, PATH variable values, and the like, they have absolutely no bearing at all on which version of TypeScript VS.NET is using and compiling against. I'll get to that in a minute. 

However every Google search for, "which TypeScript version do I have installed" yields a bunch of results saying, "run tsc -v" which ultimately reads that value in the PATH variable and confuses the heck out of people. They get concerned that VS.NET is not targeting their newer version of TypeScript installed. 

The matter of fact is that TypeScript can have multiple side-by-side installations and it's all about the project's targeted value and none of what's in the PATH variable is important. You would think if the TypeScript team wanted to use the PATH variable they would update it to the newest version upon installing a newer TypeScript version. Not so. It remains stagnant at the old version which then shows the older TypeScript compiler version thus leaving everyone confused.  I found this comment on the following GitHub thread which confirms, folks will have to update the PATH variable manually for the time being:

Before manually changing the PATH variable to point to the newer TypeScript SDK version, lets look at what VS.NET reads to know which compiler to target. Unfortunately it is not available as a nice dropdown in the TypeScript properties for the project (hence adding to my rating of '2' for the version fun with TypeScript). Instead it is in the project's properties configuration within the .csproj or .vbproj file. I particularly like the EditProj Visual Studio Extension which adds a nice 'Edit Project File' to the context menu when right-clicking a project within VS.NET. Doing this will bring up the project's configuration, and I can see the TypeScript version targeted and used by the project inside the tag:

Now VS.NET will append this value to the C:\Program Files (x86)\Microsoft SDKs\TypeScript\ path to get the compiler used for the project. In this case we know from above the 1.3 version of the TypeScript compiler is in that directory. 

Let's do a test and write some TypeScript using the spread operator that's not fully supported until ES6 or version 1.5 of TypeScript which can compile to ES5 JavaScript. Technically version 1.3 of TypeScript can still compile the following to JS but it will complain in the IDE which is what we'd expect:

Notice how we get the red squiggly under the spread operator usage (three dots ...) and a notice that this is a TypeScript 1.5 feature.

Now we can prove the tsc -v output and resulting PATH variable value are not what's being used by VS.NET (it's the Tools Version I showed above). If we change the PATH variable TypeScript directory value from:

C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0\

to:

C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.5\

...in the System variables (the TypeScript directory is embedded within the Path variable, so copy out to Notepad to locate and modify):

...and open a new command window we can see now the tsc -v command reads the updated PATH variable and outputs the resulting 1.5.0 version. 

So cool right? VS.NET should now reflect version 1.5 of TypeScript being used and our warning should go away. Nope. Save your TypeScript file, rebuild, reopen VS.NET, do whatever you feel, and you will still see the warning above. That's because what matters to VS.NET is what version is in it's own project configuration and not what the PATH variable returns via the version command.

What we need to do is manually update the project's configuration to point to the 1.5 SDK tools version (remember this should be the value of the folder that VS.NET appends to the SDK directory and not the actual compiler version). Using the 'Edit Project' tool I mentioned previously, I can change the 1.0 tools version to 1.5:

If I go back to my TypeScript file, immediately I notice the spread command is understood and accepted as we are pointing to version 1.5 of the TypeScript compiler:

So that's TypeScript versioning as of today. If you want to target a newer (or older) version of TypeScript, or just want to see which version your project is currently using, you'll need to take a look in the project's configuration for the  value.

As an aside, VS.NET will warn you if you have a newer version of the TypeScript tools installed, but your project is targeting an older version. It will ask if you would like to upgrade your project:

I can say I've had mixed results saying  'Yes' to this dialog including while writing this post. It did not update the version to 1.5 in my project's properties. I still had to manually modify the version.

To this end, I've made a recommendation on Microsoft Connect that the TypeScript tools version (and corresponding compiler version), be selectable from within the IDE on the 'TypeScript Build' tab within the project's properties. You can read and vote for this if you would like here: Allow switching TypeScript configured version from Project Properties IDE

Visual Studio Online Goes Live

Today at the Visual Studio 2013 Launch, 'Visual Studio Online' was announced and is now available for use at: http://www.visualstudio.com/en-us/products/visual-studio-online-overview-vs This was previously known as Team Foundation Service and is a home for your project data and team collaboration in the cloud. Here are the main 'features' taken directly from Microsoft's site:

• Unlimited team projects and private code repositories
• Integrates with popular IDEs, including Visual Studio, Eclipse, and Xcode
• Includes your choice of Visual Studio Express for Web, Windows, or Windows Desktop
• Build your backlog, track bugs and tasks
• Run CI builds on Microsoft cloud infrastructure for easy management of team builds

MSDN Subscribers have access included in their subscription, and small teams of less than 5 can join for free. Larger teams that do not have a MSDN subscription have additional licensing options available. As of right now, it appears it is $10 per month per user as an introductory special ($20 regular price). I'm sure the fees are just to cover the cost of the cloud services for Microsoft, as it behooves them to attract as many users to their suite of services as possible.

As you can see from above, signing in for the 1st time only takes a few minutes as I'm a MSDN subscriber and the process was simple. Looks like this could be a great tool for a number of reasons, so check it out from the link provided.

Download and Export NuGet Packages Without VS.NET

99.999% of the NuGet packages that I use are associated with a specific project in VS.NET and adding them with the Package Manager Console is trivial.  Just copy and paste the command from the NuGet site, and your done.

Interestingly enough though I came across a couple of utilities I wanted to use that were hosted on NuGet that were not application specific; specifically 'OpenCover' and 'ReportGenerator'. These are used for unit testing code coverage metrics and reporting, so I thought they needed to be added to my unit test project. After seeing how they worked I realized they had nothing to do with any project and could be downloaded independently. I can still use VS.NET to download the packages and then move them, but why clutter my app with packages that are truly not required.

There is an easy enough way to download NuGet packages separate from VS.NET and export their contents to any given directory. One method I want to show you is a quick way to download a package from NuGet without any tooling at all, and just using the browser. Find the name of your package from NuGet and append it on to the end of this URL:

http://packages.nuget.org/api/v1/package/{package name}
and then add the package to make the complete download URL like this:
http://packages.nuget.org/api/v1/package/OpenCover

Which will immediately result in the download of the .nupkg NuGet package:

Now that's a quick and easy way to get the NuGet package without VS.NET. However there is a more inclusive tool named 'NuGet Package Explorer' available from CodePlex which allows us to download and export directly. This tool can be downloaded from the following link:


NuGet Package Explorer

It's a ClickOnce package and once installed there should be a desktop icon to launch the tool:

The easier way to download a package is to select 'Open a package from online feed' from the dialog presented upon opening the application. However if you already have the package downloaded you can select the 'Open a local package' link instead:

Search for the package you wish to download and extract:

Once you select the package you are looking for and press 'OK', the package's contents will be shown. Go to FILE -> Export where you can select the export location of the package:

Upon successful export of the NuGet package you should see the following message:

Lastly, navigate to the export location you selected and verify the contents of the NuGet package exist:

That's it! There is other functionality of the Package Explorer that includes making your own NuGet package as well. However it is possible to download and easily export the contents of a NuGet package without using VS.NET.

Adding The HTML Target Schema Selection to VS.NET 2010 for HTML5 Intellisense

If you are beginning to delve into HTML5 in VS.NET say in a MVC3 project using the Razor engine for example, you will want intellisense support for HTML5. This is not difficult to do, but the 'HTML Source Editing' toolbar may not be shown by default in your VS.NET instance. To add it preform the following steps:

1. Open VS.NET but do not open any specific project. This ensures the changes you make will be for all project's opened.

2. Go to 'View -> Toolbars' and select the 'HTML Source Editing' menu item.

3. To test, open a MVC3 or MVC4 project using the Razor engine and navigate to a .cshtml view. The dropdown will now be active and the default selection will be 'XHTML 1.0 Transitional'. Change it to 'HTML5'.

4. Now try typing in the first few letters of a HTML element or attribute, like the 'Canvas' tag.

You now have the HTML5 schema validation and intellisense support.

Fixing the System.IO.FileLoadException Upon Building An Application Using A Downloaded Assembly

If you ever download applications or assemblies from CodePlex or other open source communities that were originally zipped up (.zip) and either contain references to additional assemblies within or reference the assembly in one of your own applications, you may run across the following 'System.IO.FileLoadException' exception upon building the application in VS.NET:

"System.IO.FileLoadException: Could not load file or assembly 'file:///C:\Dev\TestApp\Components\Some3rdParty.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515) File name: 'file:///C:\Dev\TestApp\Components\Some3rdParty.dll' ---> System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information."

As you can see the exception message is recommending a link on how to fix this error. The link refers to a <loadFromRemoteSources> element within the <runtime> parent element in the application's configuration file. The IDE thinks that this resource is being loaded from a network drive or a non-sandboxed environment and is trying to protect you the developer and the application from security risks.

However you can see within the exception I posted that the .dll is located within the project on a local drive. So adding any additional configuration here is not what I wanted to do.

In reality what has happened is that the .dll I extracted from the original .zip that I downloaded from Codeplex was already built (in this case it’s a 3rd party assembly and I do not have the source for it to recompile) and was automatically marked as coming from "another computer" and might be a security risk. The compiler will not allow the application to successfully build in this state with the security flag.

Removing the security flag is simple. Just navigate to the file in Windows Explorer and right-click it to view its properties. On the main tab at the bottom you will see the following:


Simply press 'Unblock' and then close the Properties window. Now rebuild your application in VS.NET and you should no longer see the exception.
I see the problem most often with using the pre-built AjaxControlToolkit.dll that comes from the .zip downloaded from CodePlex as well. However, you would not see this issue if you have the actual source code and compile the .dll yourself prior referencing.

Debugging Code Techniques In VS.NET 2010

OK so you have a problem in code either during development, testing, or production and do not know exactly how it is occurring. What do you do? For those of you that are thinking your code does not have problems or there should never be problems in the 1st place, please click here. For the rest of us in the real world, you might be thinking about a new tool like 'Intellitrace' to track down exactly when the error occurred. But not everyone has that environment created and even with using it, you still need to figure out *why* it occurred. How do we do this... DEBUG the code!

So now a lot reading this might think, "Well yeah I know all about debugging, simple stuff." That may be all and true but it surprises me how many developers out there based on questions I see asked a lot from an array of environments only know (2) buttons on the keyboard when it comes to debugging: [F10] and [F11] (Step Over & Step Into with default key mapping). Oh yeah and [F5], Start!

To be good at debugging and playing detective to track down problems or anomalies that cause problems, Microsoft has provided us with a plethora of debugging options within VS.NET. Most of the techniques have been around for multiple versions of VS.NET and *some* of the techniques still not known by a faction of developers stretches all the way back to the old VB Visual Studio IDE.

So let's review the (3) most basic debugging techniques: Step Into [F11], Step Through [F10], and Step Out [Shift + F11]. Step Into [F10] will execute each line of code, going into any method, property, etc. call. This is the most granular way to trace each line of code. Step Through [F10] will *not* go into code that makes up a property, method, etc. and rather execute that code completely without executing line by line, returning control to the developer to debug the next immediate line of code after execution has completed. The last one I mentioned, 'Step Out' [F11] is one I find under used even though this is functionality that stretches back to VBA and VB6 (ever watch someone hold down the F10 key or press it like they are tapping on a snare drum to exit out of a method?). What this does is allow the developer debugging to exit out of the method immediately allowing control to be passed back to the next line of code after the calling code to the current method was made, but still completes execution of the current method, property, etc.. This works well for the following example - let's say you have a method you are debugging and it is 50 lines of code. You need to understand what is happening between lines 5-10 and the rest is not important for what you need to know. What you would do is press [F11] to step into the method to debug and gather the information needed, but once you were finished observing lines 5-10 you want to return execution back to the caller but yet finish execution of the current method. You can do this by 'Stepping Out' of the routine by pressing [Shift + F11]. A lot better than placing a break point the line after the caller and pressing [F5] or trying to press [F10] another 30x to finish the method.

This really so far is super basic stuff and hopefully a bore or quick review to any intermediate or seasoned developer. But you know as well as I that the hard to track down issues, 'anomalies' happen all too often and there are a lot of other ways to debug and track down issues. One way I discussed previously is by using conditional breakpoints which I talked about in the following post: How to: Set a conditional breakpoint in VS.NET Ever press [F5] over and over hovering over a single variable value until the last name is 'Smith' or the value is 'x'? Well setting conditions on breakpoints to only stop execution when that condition is = True is well worth reviewing.

There are also several 'helper' tools that go along with debugging to help make the debugging process more efficient. So let's begin with a few tools to help with debugging. The 1st is 'Debug Labels'. Labels on debug points are useful to define descriptions or add attributes to help with individual breakpoints to provide information about it. This will carry over and be quite useful when exporting breakpoints as I will show next. So to begin, bring up the breakpoints window. The easiest way to do this is to press [Ctrl] + [Alt] + [B] on the keyboard. The window below shows this:


The Windows shows all active breakpoints and provides several sorting options and customizable features for breakpoints directly in the window. I will not go through them all here, so take a look and explore yourself. One very important feature to take note of in this window, is that any action you select to preform on the breakpoints will only be carried out on the actively displayed breakpoints as a result of any searches you have made. So If you have 10 total breakpoints, and preform a search that reduces the list down to 3 breakpoints, only those 3 in the search results will be acted upon. To clear any search criteria, press the 'X' to the right of the 'In Column' selection list.


In the block of code above I have set (2) breakpoints and notice they both display down in the Breakpoint Window displayed previously. What I want to do is create a label and assign it to this breakpoint. There are (2) ways to do this: either right click the breakpoint in the code editor or in the Breakpoint Window to bring up its options Window and select 'Edit Labels...'


To add a label, type in a description or attribute, and press 'Add' as shown below. There is a 64 character limit, and you can not have commas. You can add as many label descriptions through the window at a given time, and assign as many labels as you want signified by the checkbox(s) selected to the left of the requested label(s). These labels will be available for assignment to other breakpoints as well:


Once a label is created it can be assigned to 1..n breakpoints. Maybe you have a set of breakpoints that are similar and all need the same label. Another possibility is you have some sort of numeric order description. In this case the sorting ability in the Breakpoint Window is nice. Just sort the column to get the label description in order. This can help with a set of imported breakpoints or for walking through your own defined breakpoints. From this window you can search through the breakpoint labels as well. Just change the 'In Column' value to 'Labels', and type in the search criteria. The list will filter down based on the search results.


The next feature available from the Breakpoints Windows is the ability to Import and Export the breakpoints. Have you ever had that app you get out of source control and think "Ok I need to place (x) # of key breakpoints here, here, and here to do some task." Well what you should be doing is exporting your breakpoints and saving that file in source control. This is also really useful to pass along to other developers that might be working on your project. How nice for them to have descriptive (labels) pre-defined breakpoints already defined for debugging. The task is trivial: just press the save disk icon from the Breakpoints Window and the debug breakpoints will be exported to an .xml file. The import is just as simple. Just press the Import icon and select the .xml file where the breakpoints are defined. Don't forget to add these files to Source Control.

The next debugging technique helps with monitoring specific values but not having to stop execution to do so. They are called 'Tracepoints'. Have you ever been in a situation where you need to monitor a value of a variable and began writing 'Debug.Writeline' statements? Errrrr, No. Just use a tracepoint and monitor the same Output Window. This way you don't have to clutter up your code with debugging lines that later you might clear out or have to wrap in conditional #Debug statements. To create a tracepoint right-click on the actual breakpoint in the code editor or from the Breakpoints Window and select 'When Hit...'.


This will bring up a dialogue that allows you to type in some expressions to output needed information.


For example look at the following basic loop below.

For i As Integer = 1 To 10

Next

I want to place a tracepoint on the variable to see it's output in the loop. The expression I will use is as follows:

The value of i = {i}

In my case I will leave the option checked to 'Continue execution', so I can view the output, but not have to stop execution. Notice after adding the expression your traditional breakpoint is now a tracepoint which is displayed as a diamond.


Before executing the code, make sure to have the 'Command Window' present. If it is not, you can access it by pressing [Ctrl] + [Alt] + [O]. Now execute the code that will run through the configured Trace Point. Notice execution will not halt, but the expression you provided will be output to the Command Window. Notice for the simple loop, it output all of the values.


Pretty nice and all done through a tracepoint. No need for custom logging, Writeline statements, etc. This is an especially good technique for watching values during their lifetime throughout an application and helps solve the old "I swear I clear that value out...", or "Why does that variable loose value here but have value over there...', and many, many more examples.

The last (but by far not the last available technique) topic I am going to cover are 'Pinned Data Tips' while debugging. Ever hover over a value and have to remember it for later in execution, or jot down some notes about a particular debugged line of code? Well this feature is for you then. Begin by placing a traditional breakpoint on a line, and being execution of code until the breakpoint is hit. When you hover over the variable you will get it's current value. Ever notice there is a push pin on the end of the value? Yeah, go ahead and press it as displayed below.


To move the data tip around, just click and hold the pin to drag it off to the side if needed where there is more white space. You can also add comments to that data tip. Just press the down arrows, to get a text box for typing brief comments.

Notice as execution continues, or when you being a new debugging session the pinned data tip is still present! How cool, no more stickys on the screen or desk with random notes, values, etc. Notice how you will see it displayed as a blue horizontal push-pin in the pane where breakpoints are assigned in the editor. If it is on the same line as a breakpoint it will be mostly hidden.

As mentioned, once you being debugging again (even after stopping execution), you defined push-pins will reappear but there is one more useful added feature. Notice how the push-pin will display the last debugging session's value. This can be really useful to see how the code reacts to different input possibly, and doesn't require you to keep track of what the value was from the last time code ran through this breakpoint. The last value is displayed below:

Note: to clear any data tips, right-click the push-pin in the code editor and select 'Clear'.

These debugging techniques are just a small sampling of all of the available features. Feel free to add comments for any other features you find useful as well. The main point to drive home is that to be successful in software development will at one time or another require 'playing detective' and tracking down unknown issues, anomalies, or maybe just learning how code behaves line by line. To do these tasks well you have to be efficient at debugging. So if you are one of the few that admits they only knew about (2) or (3) Function keys used for debugging, try some of these and many other documented debugging techniques to help you expand your problem solving abilities in VS.NET.

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)

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.

Spell Checker Extension For VS.NET 2010

OK there is a really useful extension available for free to VS.NET 2010 named "Spell Checker". It shows misspelled words within commented sections with the traditional red squiggly line under the word as seen in Office products. Obviously correctly spelled words are not critical to an applications performance, but well formed internal documentation that reads well such as commenting is important.

You can download it for free by going to Tools -> Extension Manager and then select 'Online Gallery' from the left-hand side. In the search box type in the top-right hand corner, type in "spell checker" and search. The 1st extension created by Roman Golovin and Michael Lehenl (thank you) named "Spell Checker" is the one to download and install (shown below).



As you can see below, just hover the mouse over the misspelled word for the little box to display, which upon clicking will bring up the properly spelled words. There is also the ability to "Add to dictionary" which is nice, because often many words we use are technical and not in the dictionary.


It can also be downloaded directly from the link below:
Spell Checker Extension for VS.NET

Using Fiddler With VS.NET And The Local Web Development Environment 'Cassini'

If you use Fiddler to monitor traffic to your web sites, you have probably found it useful for debugging issues like 404's or 403's etc. However if you want to have Fiddler show traffic from sites you are debugging through your local VS.NET web development server, then you need to add a '.' period after the word 'localhost' in the URL. Also make sure to add it prior to the designated port as displayed below.

After refreshing the page, you can see the output in Fiddler.