Category Archives: 3302

Would you like to have roaming settings in Visual Studio?

The C++ Team (blog) has been researching roaming Visual Studio settings and they have a few questions that will help gain insights into what the best experience would be. They have created a survey (http://aka.ms/vsroaming) aimed at understanding Visual Studio settings usage patterns and gathering feedback. The survey should take less than 10 minutes, maybe more if you want to provide a ton of details.


Your voice is important. Make sure it is heard!

Breaking Changes In Argument List Evaluation In C# 5.0

The C# Language Specification states on §7.5.1.2 that “(…) the expressions or variable references of an argument list are evaluated in order, from left to right (…)”.

So, when this code is compiled with the C# 4.0 compiler:

static void M(
    int x = 10,
    int y = 20,
    int z = 30)
{
    Console.WriteLine(
        "x={0}, y={1}, z={2}", x, y, z);
}

static void Main(string[] args)
{
    int a = 0;

    M(++a, z: ++a);
}


and run, this unexpected output is obtained:



x=2, y=20, z=1


In fact, fixing this compiler flaw was the cause of one of the few breaking changes introduced in C# 5.0.



Using the 5.0 compiler, the expected result is obtained:



x=1, y=20, z=2


To avoid this type of surprises, expression evaluation should be avoided in argument lists.



With this code:



int a = 0;

int i = ++a;
int j = ++a;

M(i, z: j);


the same result is obtained for both C# 4.0 and C# 5.0:



x=1, y=20, z=2

Announcing The Microsoft Roslyn CTP

The Roslyn team has announced general availability of the Roslyn CTP!

The official launch is at http://msdn.com/roslyn, and there were a number of blogs to publicize the availability broadly (soma, ericli, vsteam, vbteam, c#faq) and across twitter.

This release marks a significant step to the new way of thinking of compilers, and the agility that is now possible with language innovation, IDE tooling, and powering the ecosystem. The C# and VB compilers are no longer black boxes – something we put source text into, do some magic on, and get an assembly out.  All that rich information about code is no longer thrown away, but is now exposed as a full-fidelity object model that can be easily consumed by all.  In addition, it was released a preview of the first-ever Interactive window for C# that contains full IDE support – including IntelliSense and even automatically detecting missing using directives.

How to get started:

  • Download the CTP.  The CTP installs on Visual Studio 2010 SP1 and can be safely installed side-by-side with Visual Studio 11.
  • Go to Start -> All Programs ->  Microsoft Codename Roslyn CTP -> Getting Started to launch the entry point into all the documentation, samples, and tools.
  • Read the Roslyn Project Overview for a good overview of the project.
  • Learn from the rich samples included (paste as C#/VB, refactorings, code analysis, and code generation tools).
  • Run the walkthroughs to learn about the Compiler APIs, the Services API, or using the Interactive window.
  • For those of you that aren’t extension writers, download the CTP to try out the Interactive window and use the Copy Paste C#/VB extensions that were built to help with your daily work now!

The release includes the following features:

  • Visual Studio Project Templates
    These project templates help you get started using the Roslyn APIs and building new Visual Studio extensions using the C# or VB APIs.
  • Reference Assemblies
    The Roslyn assemblies can be added to projects via the Add Reference dialog.
  • Interactive Window
    A new tool window called C# Interactive is available in Visual Studio by invoking View -> Other Windows -> C# Interactive from the menu. You can explore by either executing snippets of code in the C# Interactive tool window, or cumulatively building up execution context as you experiment.
  • Script File Editing Support
    C# Script (.csx) files allow top-level statements much like the C# Interactive window. You can create a new C# Script file by invoking File -> New File -> Script -> Visual C# Script from the Visual Studio menu. In addition to typing directly into the tool window, you can also select code in C# and C# Script (.csx) files and invoke "Execute in Interactive" or "Copy to Interactive" from the context menu. C# Script editing features like IntelliSense are powered by the Roslyn Language Service.

Please keep in mind that this is only a technology preview, and it’s not done yet! The primary goal of this CTP is to gather feedback on the public APIs and give an early look at the Interactive window feature. The shape of the APIs are in a fairly stable state, especially the Compiler ones, but there are still a set of known limitations and only a subset of the C# and Visual Basic languages are implemented in the current release.  For a full list of non-implemented language features, see here. The Interactive window is only available for C# at this time, but VB is following shortly.

The Roslyn team looks forward to hearing your feedback on the forums e through Connect.

Visual Studio 2010 Service Pack 1 And .NET Framework 4.0 Update

As announced by Jason Zender in his blog post, Visual Studio 2010 Service Pack 1 is available for download for MSDN subscribers since March 8 and is available to the general public since March 10.

Brian Harry provides information related to TFS and S. "Soma" Somasegar provides information on the latest Visual Studio 2010 enhancements.

With this service pack for Visual Studio an update to the .NET Framework 4.0 is also released.

For detailed information about these releases, please refer to the corresponding KB articles:

Update:

When I was upgrading from the Beta to the final release on Windows 7 Enterprise 64bit, the instalation hanged with Returning IDCANCEL. INSTALLMESSAGE_WARNING [Warning 1946.Property ‘System.AppUserModel.ExcludeFromShowInNewInstall’ for shortcut ‘Manage Help Settings – ENU.lnk’ could not be set.]. Canceling the installation didn’t work and I had to kill the setup.exe process.

When reapplying it again, rollbacks were reported, so I reapplied it again – this time with succes.

Is Your ASP.NET Development Server Not Working?

Since Visual Studio 2005, Visual Studio comes with a development web server: the ASP.NET Development Server.

I’ve been using this web server for simple test projects since than with Visual Studio 2005 and Visual Studio 2008 in Windows XP Professional on my work laptop and Windows XP Professional, Windows Vista 64bit Ultimate and Windows 7 64bit Ultimate at my home desktop without any problems (apart the known custom identity problem, that is).

When I received my new work laptop, I installed Windows Vista 64bit Enterprise and Visual Studio 2008 and, for my surprise, the ASP.NET Development Server wasn’t working.

I started looking for differences between the laptop environment and the desktop environment and the most notorious differences were:

System

Laptop

Desktop

SKU

Windows Vista 64bit Enterprise

Windows Vista 64bit Ultimate

Joined to a Domain

Yes

No

Anti-Virus

McAffe

ESET

After asserting that no domain policies were being applied to my laptop and domain user and nothing was being logged by the ant-virus, my suspicions turned to the fact that the laptop was running an Enterprise SKU and the desktop was running an Ultimate SKU. After having problems with other applications I was sure that problem was the Enterprise SKU, but never found a solution to the problem. Because I wasn’t doing any web development at the time, I left it alone.

After upgrading to Windows 7, the problem persisted but, because I wasn’t doing any web development at the time, once again, I left it alone.

Now that I installed Visual Studio 2010 I had to solve this. After searching around forums and blogs that either didn’t offer an answer or offered very complicated workarounds that, sometimes, involved messing with the registry, I came to the conclusion that the solution is, in fact, very simple.

When Windows Vista is installed, hosts file, according to this contains this definition:

127.0.0.1       localhost
::1             localhost


This was not what I had on my laptop hosts file. What I had was this:



#127.0.0.1       localhost
#::1             localhost


I might have changed it myself, but from the amount of people that I found complaining about this problem on Windows Vista, this was probably the way it was.



The installation of Windows 7 leaves the hosts file like this:



#127.0.0.1       localhost
#::1             localhost


And although the ASP.NET Development Server works fine on Windows 7 64bit Ultimate, on Windows 7 64bit Enterprise it needs to be change to this:



127.0.0.1       localhost
::1             localhost


And I suspect it’s the same with Windows Vista 64bit Enterprise.

Visual Studio: Setting Up The Current Project And Run

When I’m building a demo solution I usually have several projects to demo different features.


When I want to run one of the projects, I have to set it as the startup project (either in the Project menu or in the context menu of the Solution Explorer for the desired project) and start it with or without debugging.


I can start any project with debugging using the context menu for that project in the Solution Explorer, but I cannot start the project without debugging.


While preparing for my session at the upcoming Microsoft TechDays 2010, I decided to work around this by creating macros to set the current project as the startup project and start the project with or without debugging:


Sub SetAsStartUpProjectAndStartWithoutDebuggingMacro()
    DTE.ExecuteCommand("Project.SetasStartUpProject")
    DTE.ExecuteCommand("Debug.StartWithoutDebugging")
End Sub

Sub SetAsStartUpProjectAndStartWithDebuggingMacro()
    DTE.ExecuteCommand("Project.SetasStartUpProject")
    DTE.Debugger.Go(False)
End Sub


And I can bind those macros to keyboard shortcuts (Shift+Alt+F5 for starting with debugging and Ctrl+Shift+Alt+F5 for starting without debugging) and add them to a toolbar.

C# Proposal: Compile Time Static Checking Of Dynamic Objects

C# 4.0 introduces a new type: dynamic. dynamic is a static type that bypasses static type checking.


This new type comes in very handy to work with:



Because static type checking is bypassed, this:


dynamic dynamicValue = GetValue();
dynamicValue.Method();


is equivalent to this:


object objectValue = GetValue();
objectValue
    .GetType()
        .InvokeMember(
            "Method",
            BindingFlags.InvokeMethod,
            null,
            objectValue,
            null);

Apart from caching the call site behind the scenes and some dynamic resolution, dynamic only looks better. Any typing error will only be caught at run time.


In fact, if I’m writing the code, I know the contract of what I’m calling. Wouldn’t it be nice to have the compiler do some static type checking on the interactions with these dynamic objects?


Imagine that the dynamic object that I’m retrieving from the GetValue method, besides the parameterless method Method also has a string read-only Property property. This means that, from the point of view of the code I’m writing, the contract that the dynamic object returned by GetValue implements is:


string Property { get; }
void Method();

Since it’s a well defined contract, I could write an interface to represent it:


interface IValue
{
    string Property { get; }
    void Method();
}


If dynamic allowed to specify the contract in the form of dynamic(contract), I could write this:


 


dynamic(IValue) dynamicValue = GetValue();
dynamicValue.Method();

This doesn’t mean that the value returned by GetValue has to implement the IValue interface. It just enables the compiler to verify that dynamicValue.Method() is a valid use of dynamicValue and dynamicValue.OtherMethod() isn’t.


If the IValue interface already existed for any other reason, this would be fine. But having a type added to an assembly just for compile time usage doesn’t seem right. So, dynamic could be another type construct. Something like this:


 


dynamic DValue
{
    string Property { get; }
    void Method();
}

The code could now be written like this;


 


DValue dynamicValue = GetValue();
dynamicValue.Method();

The compiler would never generate any IL or metadata for this new type construct. It would only be used, at compile time, for static checking of dynamic objects. As a consequence, it makes no sense to have public accessibility, so it would not be allowed.


Once again, if the IValue interface (or any other type definition) already exists, it can be used in the dynamic type definition:


 


dynamic DValue : IValue, IEnumerable, SomeClass
{
    string Property { get; }
    void Method();
}

Another added benefit would be IntelliSense.


I’ve been getting mixed reactions to this proposal. What do you think? Would this be useful?