The icons in the Solution Explorer has a very important purpose and function. And I'm (along with half of the world, it seems) not very pleased to see that this UX functionality was abandoned during this recent redesign.

The ability to differentiate files from folders.

This is the most important information that those icons has to provide the user with. By far. And there are three facts that prevents the "Hey, I'm a folder"-information from getting to the user:
1) The icon shape does not look like a classic folder (although an esoteric, modern one)
2) The icon is black (folders tend to have a yellow tan - especially after sunny days)
3) The icon for an opened folder is not resembling anything a human is used to interacting with

I've given the RTM a fair chance, and I like it a lot. But when working with large solutions, there is no chance in [insert hot place here] that my brain can scan and identify the file I'm looking for.

I'm sure that improvements could be made to several icons, but the file/folder issue is the most important one. So please have another shot at the icons and see what you can come up with for SP1.

Best Regards,
Simeon

VIsual Studio is one of the only products I know of that has a lifetime of 2-3 years, and gets *one* update in that time.

That is ridiculous. It smells like a leftover from 20 years ago, when distributing updates was difficult. Today, it is inexcusable.

For each release, it gives you a window of perhaps two months where you're competitive. Then, for the next 2+ years, you stand still, while the competition zooms past you, after which you release a new version, and it all starts over again.

It also clashes with all your attempts at interacting with the community. Where's the incentive for anyone to run PerfWatson and help provide data to speed up VS, when any data we give you is based on what your code looked like two years ago, and any improvements won't ever be seen in the product we're providing feedback on.

It detracts a lot of value from your product, simply because you do a lot of work that, on average, is seen by us 12-18 months later.

Release updates, hotfixes, service packs, whatever you want to call them, every few months, with *whatever improvements you have*. If you have a better compiler, ship it. Better IDE performance? Ship it. Better stability? Ship it. Better usability? Ship it.

That might make vNext look a bit less impressive, but it can be sold on the promise of being constantly updated over the *next* 2-3 years. Everyone loses on the code/feature hoarding you're currently doing.

It would also make both Connect and UserVoice a lot saner and more user-friendly. Right now, we see bugs closed as "fixed", despite the fact that we can't *get* the fix for another 2 years, and then only by buying a completely new version of the product. Is it any wonder your customers are a bit grumpy sometimes?

Now that WinRT has been unveiled, a lot of people have criticized the C++/CLI-like quasi-C++ that is the recommended way to interface with the API. And honestly, it looks reasonably nice. If we're willing to give up all hopes of using another compiler than VC11, and don't mind non-standard code in our C++ application, it seem a nice way to interface with WinRT.

But how about an alternative?

How about offering a "best effort" library-only ISO C++ wrapper to make WinRT usage as simple as possible without relying on library extensions? It doesn't have to be as clean and pretty as the language extensions, but it could be a lot prettier than the raw COM interface.

Right now, we have the choice between the (basically undocumented) underlying COM, or the nonconformant language extensions. Both options obviously have their uses, but I'd love to see an intermediate layer: something that makes WinRT as easy as possible to use from ISO C++.

Please?

Just like Nullable<int> can be written as int? I would like to be able to write int* in stead of IEnumerable<int>. This would of course also work for reference types like a custom defined Person class. IEnumerable<Person> would then be equivalent to Person*.

IEnumerable<T> has become a very important type within the .NET framework and in my opinion it would make sense to include some minor syntax in the C# language to avoid to have to write the types rather long name for example when defining method parameters and return values that are enumerable. The 'var' keyword isn't allowed everywhere type names are.

When you think of it, its silly that methods by default can only return one value, but can take many arguments. Often times you want many return values, but it would be too painful to create classes/structs for each set, so often developers decide to then use ref or out parameters.

Instead what if method/function calls could return many values without the need to define a class/struct.
This example is a bit contrived but this shows the power of the fact that error information and values can easily be returned al at once.

Syntaxt like:

private {int index, bool IsError=false, string errorMsg=null} FindStringIndex(string[] strings, string stringToFind)
{

for (int x=0; x<strings.Length; x++)
{
if (strings[x]==stringToFind)
return x;

}

return {-1,true,"String not found"}

}

Usage:

string[] mystrings={"One","Two","Three"};

var val=FindStringIndex(mystrings,"Three");

if (!val.IsError)
Console.Writeline("Found index {0}",val.index);

Alternate usage (works like it doesn't even have those extra parameters but can easilyy access when you need them.:

int! index=FindStringIndex(mystrings,"Three");

if (index==-1)
{
if (index.IsError)
Console.Writeline("Error:",index.errorMsg);

}

The ! like a ? changes the int into sort of a template object, but this one allows access to the named values returned from a method. The first return value is the default but using a default keyword can change that. The default value would be the one default returned.

Alternate usage#2:
string {errormsg} msg=FindStringIndex(mystrings,"Three");

(Not very useful but this using the name of the return value pulls just the value it needs.

Alternate usage#3:
string {string} msg=FindStringIndex(mystrings,"Three");

Retrieves the one string in the return values by type rather than by name.

Personally I don't like this syntax exactly but basically looking for some way to be able to easily return multiple values from a function call without having to create more classes/structs.

Static file hosting (CDN) is by far the most cost-effective, reliable and scalable way to get content on the web. Unfortunately, Visual Studio doesn't make creating such sites easy. That's tragic since Visual Studio includes all the required technologies to create a best-in-class solution (project meta data, Razor, T4, Publishing, etc.)

A "Static Site Generator Project" would allow me to author master pages, html, content, css, javascript and "publish time" code. When published the project will generate a site than can be hosted via any static file serving service (including removable media). Operations done during publishing would include HTML generation (expansion of master pages, variable substitution, "publish time" code execution) as well as site map generation and URL rewriting that allows me to use several different server name (s1.domain.com, s2.domain.com, etc.). Ideally, it would also combine and minify JS and CSS, create sprite images and data URIs where applicable, and pre-compress (gzip) files where appropriate.

Please recognize that not all sites include server-side dynamics (because with SaaS we are equally likely to use a third party or API site via AJAX), and add project types for static sites that can be published to file systems, FTP or CDN hosting directly.