Simply awesome, here is the announcement from Microsoft:
Visual Studio for Mac - Introducing Visual Studio for Mac
Very interesting video by Kaycee Anderson on Visual Studio 2015 debugging:
TypeScript 2 has been released (to be exact: version 2.0.3).
As by TypeScript 2.0 is now available!, the principal innovations are:
- Definition file acquisition via npm
This change is in line with the new Microsoft guideline to use npm (or bower) to acquire client side libraries (and still use NuGet for server side packages); it is also coherent of letting users leverage the TypeScript language even on non-Windows computers, in particular on Mac and Linux, where you can use Visual Studio Code
- Non nullable types
It's confirmed that this is a breaking change, so you have to set strictNullChecks to true in your tsconfig.json (by default it is false). Clearly it's strongly suggested to do so
- Control Flow Analyzed Types
Even more expanded from what already available in TypeScript 1.8
- Readonly modified
Similar to what available in C#
An even more detailed list of the language innovations is in What's new in TypeScript. And also give at look at the Breaking Changes.
Finally: you can start using it in Visual Studio 2015 downloading the TypeScript for Visual Studio 2015 plugin (it requires the Update 3).
If you upgrade to TypeScript 2 (incidentally, done automatically by installing VS DEV15), you can get the following errors in a web project containing TypeScript files:
- The "VsTsc" task could not be initialized with its input parameters.
- The "OutputLogFile" parameter is not supported by the "VsTsc" task. Verify the parameter exists on the task, and it is a settable public instance property.
You need to open a Notepad as administrator and edit the file C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v15.0\TypeScript\Microsoft.TypeScript.targets, removing the OutputLogFile parameter.
Visual Studio 2015 didn't allow SharePoint 2013/2016 WFM (Workflow Manager) development, so far.
The problem is because installing .NET 4.6 was breaking Service Bus 1.1
There is a patch fixing it: Update for Service Bus Server 1.1 (KB3086798)
Visual Studio 2015 introduces the new Android emulator. What is great is that it is based on Hyper-V technology, so hardware virtualization, as described more extensively in Introducing Visual Studio’s Emulator for Android.
Using it to develop Xamarin application, I've run into some issues, and I think that it would be good to collect them here:
- first of all, during my first attempt to run it to debug a simple application, I got in the Output windows of Visual Studio this cryptic error:
In mgmain JNI_OnLoad
Couldn't connect to logcat, GetProcessId returned: 0
As described in Can't run app on Visual Studio 2015 emulator (DWP Handshake failed), the solution is to go to the Android project settings and in the Android Options tab, disable Fast Deployment
- the second problem was that because of my naming convention for demo projects, I had a too long project name.
Doing some attempts, I've verified that the longest project name you can give is 37 characters (more create problems with the deployment);
- when I've been finally able to run my application, I've noticed that I had multiple graphic issues (even if the application is really basic).
As described in Visual studio android emulator will not start fully, you have to go to the folder C:\Program Files (x86)\Microsoft XDE\10.0.10240.0\SKUs\Android, edit the file xdesku.xml and delete/comment the line:
When you develop with Entity Framework, you may need the SQL instruction passed to the SQL engine when your LINQ query is evaluated.
As you can see from the post ToTraceString Method in Entity Framework, both the System.Data.Objects.ObjectQuery and the System.Data.EntityClient.EntityCommand classed implement the ToTraceString() method, whose evaluation returs just the info you need.
An update in EF 6.1 allows to output the generated SQL doing:
context.Database.Log = Console.Write;
after having created the context, as explained in Logging and Intercepting Database Operations.
In Visual Studio it's possible to edit and debug PowerShell scripts, using the PowerShell Tools for Visual Studio 2015 extension.
But even after installing the extension, debugging doesn't immediately work, as trying to do this, the output window simply shows an unauthorized access error message.
I've found the blog post PowerShell Tools for Visual Studio 2013 – unable to run and/or debug PowerShell script – execution policies problem that has helped me in finding the solution:
- from a PowerShell window with elevated privileges,
- run the command "Set-ExecutionPolicy" RemoteSigned
For one client I had to solve the problem of NuGet packages in nested solutions, where piratically there is one big solution file (used mainly by the build server) and many other nested solutions used by the various developer teams.
The solution in Nuget with multiple nested solutions simply works, but it uses an absolute path, so there can be issues when using the solutions from different machines (developer configurations, build server, and so on). The goal is to use relative paths.
Another long thread is Setting up a common nuget packages folder for all solutions when some projects are included in multiple solutions and it shows multiple alternative (even because meanwhile the tools has improved so many steps are no more necessary).
One example of configuration file can be downloaded here: NuGet.config (514B)
The only important things to note are:
- the packages paths are relative to the .nuget folder
For this, in Visual Studio 2013 you can find the HTML UI Responsiveness Profiler.
Here a few links on this topic: