The XML PSI tree doesn't provide many strongly typed methods for manipulating the tree. The IXmlTag and IXmlTagContainer nodes are the only ones that provide methods.
public inteface IXmlTag
{
// ...snip...
TXmlAttribute AddAttributeAfter(TXmlAttribute attribute, IXmlAttribute anchor);
Visual Studio's "Experimental Instance" feature is intended for developing and debugging Visual Studio extensions, and maintains a separate copy of the configuration needed to run Visual Studio. Each experimental instance can have an entirely different configuration, from theme and window layout to the extensions that are loaded.
Note "Experimental instances" were previously known as "custom hives"
By default, ReSharper (and the other .net tools, dotCover, dotMemory, dotTrace, etc.) are installed as per-machine Visual Studio extensions. This means that they are available to all users on the machine, but also that they are loaded in all experimental instances.
The Platform layer that provides Visual Studio integration to ReSharper and the other .net tools, has support to move its registration from per-machine to per-user, and per-experimental instance. This allows for ReSharper (dotTrace
| using System.Collections.Generic; | |
| using System.IO; | |
| using System.Linq; | |
| using JetBrains.Application; | |
| using JetBrains.Application.Progress; | |
| using JetBrains.DocumentManagers.impl; | |
| using JetBrains.ProjectModel; | |
| using JetBrains.ReSharper.Psi; | |
| using JetBrains.ReSharper.Psi.Caches; | |
| using JetBrains.ReSharper.Psi.Tree; |
| [Test] | |
| public void TestSomething() | |
| { | |
| Lifetimes.Using(lifetime => { | |
| // Defined in BaseTest. Injects a writable storage at high priority | |
| // to accept changes to settings, and which is thrown away when the | |
| // lifetime terminates | |
| ChangeSettingsTemporarily(lifetime); | |
| var settingsStore = ShellInstance.GetComponent<ISettingsStore>().BindToContextLive(lifetime, ContextRange.ApplicationWide); |
| /// <reference path="angular.js"/> | |
| /// <reference path="angular-mocks.js"/> | |
| /// <reference path="~/app/myApp.js"/> | |
| describe("The moviesCtrl", function () { | |
| 'use strict'; | |
| // this is useful - will cause the browser running the tests for ReSharper | |
| // to pause in the debugger, then using the normal dev tools, see what | |
| // scripts are loaded, and (importantly) in what order |
| fun get(url: String, headers: Headers = Headers()): Observable<Response> { | |
| //return getWithExplicitClass(url, headers)!! | |
| //return getWithAnonymousClass(url, headers)!! | |
| //return getWithInlineUsingObsoleteSubscribeFunc(url, headers)!! | |
| return getWithFailingInlineFunction(url, headers)!! | |
| } | |
| fun getWithFailingInlineFunction(url: String, headers: Headers = Headers()) : Observable<Response>? { | |
| // This fails. Looks like a bug in Kotlin: http://youtrack.jetbrains.com/issue/KT-4598 |
ReSharper 8 extensions get automatic loading of settings + annotations from within the package. VS2008+R#8 doesn't support extensions OOB, since extensions are nuget based, and that requires .net 4. VS2008+R#8 can still load plugins, but then they have to manually load settings and annotations. Here are two ways to do it. Which is best?
The first file re-implements the settings and annotations loaders. Annotation loading is dead easy thanks to a simple interface. This can easily be hand written. Settings requires more legwork to add a file to the Extensions layer (provided by ReSharper 8). This would probably be a bit of copy and paste from the plugin devguide.
The second file implements a custom extension provider, in the same way as ReSharper implements the nuget package support. It creates an extension based on the loaded plugin, and publishes it to the system in the same way the nuget implementation publishes nuget package extensions. So the default annotation and settings loaders then ask the extension
Simple example for ReSharper 7.1 to include non-project files into the project system. This particular example will include a file called Hidden.cs that lives in the root of a C# project into the project.
This means that the declarations inside Hidden.cs are now available for ReSharper to use - types defined in Hidden.cs now appear in code completion lists, and other symbols are also resolved. Navigation also works, after a fashion.
This is useful if you have a project that declares some files as included in the project, but marked as hidden. Since ReSharper gets its project information from Visual Studio, and since the "hidden" metadata means the file is excluded from Visual Studio's file tree, ReSharper doesn't get to know about the file. This sample could be extended to interrogate the msbuild based project system and find all hidden files and expose them.
An alternative use could be providing simple support for transpiled languages, such as Less, SASS and CoffeeScript. While those languages wouldn't h
Edit the "Class" File Template (ReSharper -> Templates Explorer -> File Template -> C# -> Class) to be this:
$HEADER$namespace $NAMESPACE$
{
$SELSTART$// File: $FILENAME$.cs$SELEND$
public class $CLASS$ {}
}
| using System.Reflection; | |
| using JetBrains.ActionManagement; | |
| using JetBrains.Application.PluginSupport; | |
| // General Information about an assembly is controlled through the following | |
| // set of attributes. Change these attribute values to modify the information | |
| // associated with an assembly. | |
| [assembly: AssemblyTitle("TypingAssistManagerTest")] | |
| [assembly: AssemblyDescription("Example of how to hook into typing assist handler chain")] | |
| [assembly: AssemblyConfiguration("")] |