In C# there is a feature of the language that allows a method to receive as input parameters the member name, file path and line number of the calling method/property.
It is enough to add attributes to the method parameters receiving these values, as in the following example:
public void DoProcessing()
public void TraceMessage(string message,
[System.Runtime.CompilerServices.CallerMemberName] string memberName = "",
[System.Runtime.CompilerServices.CallerFilePath] string sourceFilePath = "",
[System.Runtime.CompilerServices.CallerLineNumber] int sourceLineNumber = 0)
System.Diagnostics.Trace.WriteLine("message: " + message);
System.Diagnostics.Trace.WriteLine("member name: " + memberName);
System.Diagnostics.Trace.WriteLine("source file path: " + sourceFilePath);
System.Diagnostics.Trace.WriteLine("source line number: " + sourceLineNumber);
You can see that this feature can be particular useful during tracing.
The example above has been taken from Caller Information (C# and Visual Basic).
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:
With SharePoint 2013, .NET 4.5 has met the SharePoint world, allowing for example to use the latest versions of the Entity Framework during custom solutions development.
And finally, Visual Studio 2013 will carry MVC development! You can read more info in the blog post Introducing MVC support for apps for SharePoint.