We are trying to translate a whole Javascript project into Typescript. In this project we use a variable called Storage, which is a keyword/protected word in Typescript.
This variable is used a lot, and it's a bit tricky to change it, so I'd prefer to change the Storage in the definition file lib.d.ts. But I'm not able to tell Visual Studio to use this new version of lib.d.ts, it always throws an error at compilation, even if the Intelli-sense is working correctly.
Is there a configuration thing I can change somewhere ?
Thanks
The lib.d.ts file simply describes what will be available at runtime, in this case the DOM Storage interface.
Removing the clash in lib.d.ts won't remove any clashes at runtime.
One possible temporary fix is supplied by the fact that interfaces are open in TypeScript, which would allow you add to it, for example, you could include the following instead of changing lib.d.ts in order to get compilation...
interface Storage {
myCustomThing(a: string): number;
}
This will allow you to compile and get your code base into TypeScript, at which point you can use Visual Studio to refactor the name of your Storage variable to avoid the clash.
Here is a working version on the TypeScript Playground.
I doubt that it's possible to change it in Visual Studio. You may want to take a look at here:
http://typescript.codeplex.com/discussions/429115
Related
Is there anyway within Visual Studio / TFS to identify which project produces which dll?
I'm aware you can look under a particular project's properties and see what the name of the dll is, but in the circumstance where you have loads and loads of projects this doesn't seem very efficient.
I've got the situation where I've got a project that references a dll, which includes a method I want to examine, but I don't know what project produces this dll.
Unfortunately, no. The only way I know is that you may could use a decompile extension. (Strongly not recommend to use) Through the source code after decompile, you can view namespace and judge which project produces the dll. (Under normal circumstances)
And you may also have to face some problems such as:
Legal issues
Need to pay for the extension
Only work for C#/.Net
The source code may be confusion and not standard
This should be a one time activity, you can go ahead and take a look into the project file, in case of C# project the csproj file.
If you do not want to do it opening each file, then i would say write a small tool to read all the project files and look for the name.
BTW, this will be different for different projects, and you need to find out the proper location to look.
What I like to do is compile a custom file to generate a C# file. I only need it to compile when its been changed but compiling everytime is ok.
When I looked around I kept finding reference to Custom Tool and found this pretty good article. I remember pre2010 I was able to have a build rule for extensions but it looks like that doesn't exist anymore? It allowed me to specify an extension and bin+args to run against when the file changed. Whats the closest thing to that? It looks like it no longer supported which is exactly what I want
Custom Tool requires me to mess around with registry, create a dll and requires VS SDK. Its way overkill for something I done with ease in the past.
How do I have visual studios run my exe to build a custom extension source file without going into overkill like custom tool above? Must work for C# project, C++ projects would be nice but not required.
I am making changes to a Visual Studio wizard that creates a project from a template, and needs to add a reference to an assembly to the project that also lives in the extension directory. So I need to set the <hintpath>.
I have not been able to figure out how a running VS extension can discover its extension directory, which is a directory name like this:
%USERPROFILE%\AppData\Local\Microsoft\VisualStudio\10.0\Extensions\myCompany\myExtension
Using System.Reflection.Assembly.GetExecutingAssembly().CodeBase yields:
"C:\Windows\Microsoft.Net\assembly\GAC_MSIL\myCompany.myExtension\v4.0_1.0.0.0__936015a19c3638eb\myCompany.myExtension.dll"
Unfortunately, not helpful. Using GetCallingAssembly() is no better--it points at another directory in the MSIL_GAC.
Is there a Visual Studio interface that returns this information? I haven't been able to find it.
If that's not possible, is it at least possible to determine if the extension is running in the experimental instance vs. non-experimental? I could use that information to locate the extension directory.
Maybe look at IInstalledExtension.InstallPath. You can get an IInstalledExtension via an IVsExtensionManager.
Unfortunately, the message in the remarks suggests this is not the right way to do things:
Although this API supports the Extension Manager infrastructure, we recommend that you do not use it because it is subject to change.
EDIT: Here's the code:
static IVsExtensionManager GetExtensionManager()
{
return myPackage.GetService(System.typeof(IVsExtensionManager)) as IVsExtensionManager;
}
static IInstalledExtension GetExtension(string identifier)
{
return GetExtensionManager().GetInstalledExtension(identifier);
}
static string GetExtensionDirectory(string identifier)
{
return GetExtension(identifier).InstallPath;
}
The string identifier is whatever you put in the "ID" field of your extension's source.extension.vsixmanifest file. It defaults to the package GUID.
Sorry for digging up an old answered question...
I was looking into a similar problem, and have implemented the Extension Manager, but decided this is just pretty awful, though if you do want to do use it these links will also help:
https://stackoverflow.com/a/24294185
http://blog.ninlabs.com/2011/04/auto-update-visual-studio-extensions/
However, I decided to look into how the CodeGenerator in Asp.Net.Scaffolding accessed template files. Turns out, very easily...
var path = Path.Combine(Path.GetDirectoryName(GetType().Assembly.Location), "MyPath");
Simples
Is there any way one can define for a solution a global variable accessable by any project file or project property sheet included in the solution?
One variable is enough if that can define a path for a property sheet that every project can include.
This is desirably for a solution.
An environment variable would be ok though less desirable.
** (visual studion 2010)
Poking at it again, I can't see how to set a user defined $(xxx) vartiable in a project - yes you can in a property sheet, but In a project I have reference to the $(ProjectDir) -
The problem is I want to define a $(tree of projects root) that any project that references a specific poject can access and the root will be relative to that project.
An alternative would be if a property sheet can have access to its own path and define the project collection root (of a tree of related projects with common resources) relative to that.
It seems every one building a big system with VS has the same problem.
I don't know your use case but it doesn't sound like the best idea. This will tie all of your projects together very tightly, which violates good OO design. Microsoft hasn't included any solution-level properties for this reason. However, if you really want to do something like this, you have two ways (at least) to go about it.
The first way, and the way I would recommend against, would be to store the variable in one of your projects and make it public. Then all of your projects could access it as long as they include the project as a reference.
The second way, and the way that will retain some OO principles, would be to create a config file that all projects looked at for the variable. This could be an XML file, a CSV file, or even a simple text file. If you wanted to get more complicated, you could point to a database location since this is one of the roles of a database.
That the logical follow-up for the my previous question: "How to check all projects in solution for some criteria?"
I was given quite a good answer to use CustomAfterMicrosoftCommonTargets, CustomBeforeMicrosoftCommonTargets. They do work, so I decided not to stop in the middle.
Issue is that I don't want machine-wide tasks. It's not a good idea neither for me (it will affect other builds. sure, this can be handled, but still), nor for my teammates (I don't want to let them put something in system folders... ), nor for build server.
What is needed: solution to be built from scratch out of source control on clean machine with either Visual Studio or MSBuild.
It appeared that Custom*MicrosoftCommonTargets are regular properties.
So, how to specify this property? It works pretty fine when to set it from command line.
That's strange, but it appears that bit of magic present here: property passed as command line parameter to one build is transitively passed to all nested builds!
That's fine for build server. But this won't work with Visual Studio build. And even declaring solution-level property won't help: neither static, nor dynamic properties are transfer to nested builds.
...I have a hacky idea to set environment variable on before solution build and erase it on after. But I don't like it. Any better ideas?
I use a bit different technique then #Spider M9. I want that all projects in solution tree/all subdirectories from current directory use extended build throw Custom*MicrosoftCommonTargets. I don't like to be forced to change every new project to import custom targets/props.
I place special file, let's say msbuild.include, in the root directory and my custom targets loader for every project tries to find it in ., ..\, ..\..\, and so on. msbuild.include contains flags that triggers execution of custom actions. If loader can't find this file it disables loading all custom targets and stoppes. This gives me ability to use my build extensions with projects from work repositories and to not use with opensource projects.
If you are interested in I can publish loader. It's a pretty simple and elegant solution.
For example I can sign any assembly in all projects in all subfolders with my key.
I always set up every project to import a standard .props file. Use the GetDirectoryNameOfFileAbove property function (see MSDN) to find it. Do this as the first line of every project file. Once established, you can redirect from that file to other imports. Another trick is to have that standard import (that would obviously be under version control) import conditionally another .props file only if it exists. This optional file would not be in version control, but is available for any developer to create and modify with their own private/temporary properties or other behavior.