I'll be debugging a site in Visual Studio 2010 and editing an *.aspx or *.ascx file, and without warning, it will lock up so that I can't edit it. There's no message or anything, I just can't type or make any changes.

The only way to start editing again is to stop debugging, close the editing window, and then find whatever file I was working on and reopen it. It's a huge pain in the you-know-what.

My colleagues are experiencing the same thing, so it's apparently not something with my particular setup.

What's the explanation, and how can we make it stop?

---

Note 1: I've reported this to Microsoft here. If you've experienced this as well, please go there and vote up the bug report.

Note 2: This is not VSS-related, at least in my case. We use VisualSVN, which doesn't use file-system-level locking to mark files as checked out.

I've found a temporary workaround-solution: Right-click on the file and select "Open with...". Now select "Source Code (Text) Editor" and you can edit the file again but without IntelliSense :-( But you won't need an external editor.

Nevertheless we still have to wait for Microsoft to find a better solution.

I find this behavior of TryCast in .NET 4.0 / VS 2010 rather confusing.

In my understanding TryCast works like DirectCast, but will return Nothing instead of throwing an exception if a conversion is not possible.

VS 2010 / .NET 4

?TryCast(CType(1, Object), String)
Nothing
?DirectCast(CType(1, Object), String)
"1"

VS 2008 / .NET 3.5

?TryCast(CType(1, Object), String)
Nothing
?DirectCast(CType(1, Object), String)
Cannot convert to 'String'.

The .NET 3.5 results are consistent with what I believe TryCast does... .NET 4 however is not.

Can someone please point me in the best direction to securely cast an object to String in .NET 4?

Based on your code samples starting with the ? I'm guessing you're using the immediate window to perform your test correct? The problem with this approach is that the immediate window is an interpretation instead of an actual evaluation. This leaves it susceptible to subtle corner case bugs and this is indeed one of them.

If you take your sample code and add it to a simple VB.Net console application you'll find that the 2010 behavior is identical to the 2008 behavior (throws an exception).

EDIT

So why did this regression happen? In 2010 I completely rewrote the VB EE debugging engine (expression evaluator). The older code base I inherited was simply too costly to maintain anymore. To the point that adding new features to the engine was more expensive that rewriting it from scratch with a better architecture that included the new features.

As said before debugging evaluations is an interpretation more than an execution of code. It forces the duplication of some algorithms between the EE and CLR / Compiler. One of the areas where duplication occurs is in the casting logic. There is no way to ask the CLR debugger to cast a debug time object, it's the responsibility of the EE to determine if the language specified cast is indeed valid.

The old EE casting logic had numerous bugs (especially in the area of generics and arrays). The newer infrastructure conforms very closely to the CLR guidelines. However you'll never have 100% parity because it would disallow very useful expressions in the EE (I may write a blog post on this in the future). But for most cases the behavior holds.

In this particular instance I added a subtle bug which allows for a DirectCast of a value which is typed to Object to use VB's Runtime Conversion operators vs. the specified behavior which only allows for CLR conversions. Hence this conversion succeeds where it should fail.

Came across this curiosity recently.

One solution, with two projects within it (ORM and website). Visual Studio 2010 Ultimate on both computers, setup identically.

Solution and projects created on computer A, all .aspx pages have .designer.cs files.

Solution and projects copied to computer B and new web pages added, all new .aspx pages do not have .designer.cs files although the website still works fine.

Move new content back to computer A, and it now errors on rebuild with errors relating to the missing .designer.cs files.

Why would this happen? Why would two VS2010 installs handle this differently with the same solution and project files?

Right click on .aspx, choose "Convert to Web Application".

Reason: because your 'home' computer is certainly different from work computer, it can be many things. Corrupted VS template, some VS addin, .net framework, anything.

Problem with generating designer.cs is occuring since VS 2003, so answer to your 'why' question lies within VS internals.

I'm trying to add some Model properties into my JavaScript within my content page:

$(document).ready(function () {
    createPager(1, <%=Model.TotalPages %>);
    createUnprocessedPager(1, <%=Model.TotalUnprocessedPages %>);
});

Does anyone know if this is by design? Are you not meant to combine Model properties with JavaScript? Or is this a bug?

This works as expected. However, I do not have any Intellisense within the <% ... %> tags when actually writing the code. If I write any code within <script> tags, then there's no Intellisense. If I go directly under the tag </script> and type <% Model.... %> then boom, I have Intellisense again.

UPDATE: 22/10/2010

Just read Scott Guthrie's latest blog post and it appears this functionality is coming out soon with the up coming release of ASP.Net MVC 3 (possibly for the beta as well):

Note: Visual Studio Code/Markup Intellisense and Colorization within Razor files aren’t enabled yet with the Beta earlier this month. You’ll see this show up in a few weeks though – and it will support full code intellisense for HTML, JavaScript, CSS and C#/VB code within Razor files.

You will loose you Intellisense in the views inside quotes "" like attributes.

<input type="text" value="<%= DateTime.Today.ToShortDateString() %>" />

or if it appears inside of Javascript blocks.

<script type="text/javascript">
    <%= DateTime.Today.ToShortDateString() %>
    </script>

It is my opinion that there should be Intellisense in these scenarios, so I would say it is a bug and hope future updates to Visual Studio will address and resolve this.