I am using Visual Studio 2013 Update 2 with Web Essentials latest version.
At the moment typescript is giving me a hard time as AMD compiling does not seem to be reliable. Most of the time intellisense is happy with the module path (not always) but the compiler never accepts it.
This is what my file structure looks like:
-scripts
-app
-controls
FeedbackControl.ts
-models
FeedbackModel.ts
FeedbackControl.ts
import model = require("../models/feedbackmodel");
export class FeedbackControl{
constructor(){}
}
FeedbackModel.ts
export class FeedbackModel{
constructor(){}
}
This looks valid to me and even the IDE is ok with it. But when I try to compile this is what the compiler thinks:
Build: Unable to resolve external module '"../models/feedbackmodel"'.
On a side node:
Now and then the IDE is showing me such errors, too. A restart of visual studio helps. What always leads to an error is when I do not use lower case characters in module path only. Like so:
import model = require("../models/FeedbackModel");
I have no idea what I need to do to get this fixed. My team mates are having this issue, too, so I guess there is something wrong with the solution. As a workaround we disabled typescript compiling on each .ts file.
The string casing of the import statement i.e. /models/FeedbackModel needs to match the case used in the file system.
Related
When I open a generated solution+project file, I get the following warning for each platform I have in the project file:
path/to/project.vcxproj : warning : Platform '[some_platform, 0]' referenced in the project file 'project' cannot be found.
some_platform is a valid platform in the project, and building, browsing etc all work normally. There is no line number showing where the problem is.
My question is, what does '[some_platform, 0]' really mean?
Coming from Linux, I initially thought the quotes signify that I have [some_platform, 0] literally specified somewhere, which I don't. I don't see ,\s*0 used anywhere in the project file either. How do I decipher that message to be able to find out what it's complaining about?
This is a C++ project if that matters.
Edit: The only places , is even used are inside two messages and an SDK reference. So the [some_platform, 0] is definitely something constructed for the sake of warning, but what does the second part (0) mean?
Resolved: Why VS generates an output like that, I don't know, and who knows what the 0 means. However, it turned out that the platform name is something an SDK would register with VS (or something along those lines) and VS expects it case-sensitive. I had changed ORBIS and Durango to orbis and durango, causing the warning. Fixing the case makes the warning go away (the project was loading and building fine regardless).
I think you might have unmatched solution/project platform and build configurations, resulting in the rare case when visual studio defines or creates new ones: https://msdn.microsoft.com/en-us/library/kkz9kefa.aspx ending in the odd platform names '[some_platform, 0]', '[durango, 0]' and '[orbis, 0]' you have.
Now this is entirely my guess (since I could not find any documents to confirm it). But what that 0 actually means, is the reference to the default build configuration that project should use when you target those individual platforms. For instance, you usually have lines similar to this in the solution (.sln) file:{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}.Debug|Mixed Platforms.Build.0 = Debug|Any CPU
In the case above you would use build configuration 0 as the default build configuration when using msbuild solutionname.sln from the console. But since the entire platform was generated for that project, we of-course don't have a default build configuration either, so... lets generate. There is more details and examples of the default build-configuration in this post: Visual Studio solution file - what does the "Build.0" mean?
Now back to what might actually be your real problem. You mentioned SDK references, have you made sure they are pointing to the correct place and any environment variables is properly configured in visual studio? If not, the problem might be related to the warnings mentioned here:
Platform 'Android' referenced in the project file 'san-angeles' cannot be found. The warning message on that question sure looks similar to the warning you have, only you have those oddly generated platform names.
Hope this will help you solve the problem.
I'm developing an app in typescript (in Visual Studio 2015) and have this basic file structure:
Solution
AppProject
Scripts
framework
Utils.ts
app
SomeApp.ts
tsconfig.json
Now within the app modules, I would like to reference the framework modules with an absolute path, so I would do something like this:
import { Utils } from '/Scripts/framework/Utils'
However this doesn't work.
I'm getting the red squiggly line and a "Cannot find module '/Scripts/framework/Utils'"
I works fine when doing a relative path, but the app is obviously more complex than what is shown, and I don't want to deal with stepping out multiple levels for my relative path.
I am using typescript 1.8 with the node module resolution strategy.
And webpack to compile and bundle it, if that matters
Unfortunately I couldn't find anything on that in the docs. So I traced the file system accesses performed by the compiler (TypeScript 2.5.2) when trying to resolve an import of an absolute path.
The result is that / always refers to the file system root. Regardless of compilerOptions like rootDir, rootDirs or baseUrl.
Recently installed new TS version into VS2013 and tried to use protected modifier.
However TS validator shows me an error (and underlines protected word with a red line.
I get an error like
Use of future reserver word.
; expected
looks like it's looking into old TS definitions.
Checked the project file and there is 1.1 version of TypeScript.
also running tsc -v produces 1.3.0.
Does somebody of you guys experience that?
What i'm missing and what to do to fix that.
Thank you a lot for any help.
export class SomeClass {
protected metadata: Metadata;
protected subItems: SomeClass[];
constructor() {
}
}
thank you all guys. for your answers!
the reason was (oh, what's the shame =) ) the ReSharper.
It's validation was showing that error, suspending it i'm getting no errors now.
Looks like JetBrains guys should update their definitions like Web Essentials did.
As they aren't compatible with new TS version, 1.3. And no updates pending as for now.
Hope, it'll be useful for somebody else.
The answer to your question then is ReSharper 9.0 EAP.
It supports TypeScript 1.3 features: 'protected' modifier and tuples.
You're welcome to try it. Though, yes, it's a pre-release version, so overall stability is not strictly guaranteed.
Are you building from within Visual Studio, or from the command-line? What with different versions of the SDK being installed, as well as potentially the NPM package globally (if you've ever installed that), it can get quite messy as to which version gets picked up. For example, if I run 'where tsc' from the command prompt, I get the below hits (and this is without the 1.1 SDK on the path, though I am in the bin folder for testing the latest bits)
S:\src\TypeScript\bin>where tsc
S:\src\TypeScript\bin\tsc
S:\src\TypeScript\bin\tsc.js
C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0\tsc.exe
C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0\tsc.js
C:\Users\billti\AppData\Roaming\npm\tsc
C:\Users\billti\AppData\Roaming\npm\tsc.cmd
Can you verify via "where tsc" the locations and order you PATH is resolving the 'tsc' command?
That said, if you're building from within a VS project, it should locate the latest SDK via the build target. Does this also occur with a new TypeScript project (where the latest version and targets file should be referenced)?
Failing that, and I hate to say it... ready... did you try rebooting? :-) Sometimes updates to the PATH etc.. after an install don't get picked up until processes restart, and things like MSBuild can actually linger waiting for the next build as a perf optimization, rather than exit once the build is done (and thus may not pick up environment changes immediately).
It didn't work for me too. What I did to fix it was installing VS2013 Update 4 and after that, I executed the TypeScript 1.3 setup again and did a repair.
Also, you should make sure you don't have <TypeScriptToolsVersion>1.0</TypeScriptToolsVersion> in your csproject defined. Set it to 1.1 (not 1.3) or remove it entirely (then it will use the latest one). Hope that helps!
You can determine whether the issue is related to Visual Studio pointing at the wrong TypeScript version by following these steps.
Place this example code in C:\Temp\app.ts
interface Metadata {
something: string;
}
export class SomeClass {
protected metadata: Metadata;
protected subItems: SomeClass[];
constructor() {
}
}
export class OtherClass extends SomeClass {
constructor() {
super();
this.metadata = null;
}
}
var x = new SomeClass();
// Not allowed
// x.metadata = null;
Run the command:
C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.1>tsc --module amd c:\Temp\app.ts
Taking care to ensure you are pointing at the 1.1 folder in the TypeScript SDK folder.
The output should be:
C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.1>
i.e. nothing, except you now have an app.js file.
You can also re-run the test after uncommenting the x.metadata = null; line - at which point you should get the error:
c:/Temp/app.ts(22,1): error TS2445: Property 'metadata' is protected and only accessible within class 'SomeClass' and its subclasses.
Next Steps...
If the above fails, please supply details of the problem.
The only real answer we could give though it remove it and check the 1.1 folder is gone before re-installing it by fetching the installer fresh from the Microsoft website (perhaps you have a bad installer or there was some problem during installation?) You may also want to check that you are on Visual Studio Update 4, as I am testing it on Update 4.
If the above worked as expected, your Visual Studio is not pointing at the correct version.
This could be because of the project file as Dick van den Brink has correctly mentioned. Check that you have <TypeScriptToolsVersion>1.1</TypeScriptToolsVersion> and that it is the only element with this name.
It can also be down to any Visual Studio extensions that may be messing with your TypeScript (for example, if you had a really old version of Web Essentials - in which case, update it - if it is some other extension, try disabling it).
And at first, sorry for my bad English. It is my first project in D. And my first project with SFML (DSFML of course).
I use dub for making Visual Studio project (I use VS2010). Then
open it and set up project settings:
general
compiler
linker
Autocomplete works correctly:
When I try build project, here is error:
Error 42: Symbol Undefined _D5dsfml8graphics12__ModuleInfoZ
How I can resolve it?
This particular error is saying that it can't find the actual D code for the library. It could mean that dub isn't grabbing/linking the source somewhere, but I've never used dub with an IDE so I can't be sure.
My suggestion to help you figure out what is going wrong and to fix this issue is to bug the maintainer (who is me, actually) on github by opening an issue about a lack of tutorials for the IDE's that are available to D right now.
If you want to get started with DSFML right now, however, you can sort of follow along with the command line tutorial and use that as a basis of figuring out what libraries need to be linked in, set up import search paths, etc.
Create project by dub init dsfml_test (where dsfml_test is our project name)
Add libs dependencies to dub.json
Generate Visual Studio project
Open project in Visual Studio
Open project properties
Enter path to directory where is placed dsfml lib files
Thats all. Now can add import dsfml.graphics, dsfml.window, dsfml.system; ...etc and build project.
When dynamically referencing assemblies in .fsx using #I and #r, VS highlights the following usages of imported types and writes "The namespace or module 'XXX' is not defined". Is it ok?
For example, in the following code
#I #".\Tools\FAKE"
#r "FakeLib.dll"
open Fake
Target "Hello" (fun _ -> trace "hello!")
Run "Hello"
VS highlights Fake and says "The namespace or module 'Fake' is not defined", it also highlights Target and Run. I have this problem in VS 2010 SP1 and in VS 11 CTP. This issue makes writing F# scripts a bit harder task than it could be.
By the way, IntelliSence for "common" types works well. FakeLib.dll and FakeLib.xml are present in the .\Tools\FAKE directory. The code runs well.
Update 1
Here's the screenshot of the situation. You can see that VS resolves assembly FakeLib correctly (in a tooltip), and that at the same time Intellisense "see" standard types (tooltip over Console) class.
Update 2
I think there's something wrong with the IntelliSense on my work workstation, because it (IntelliSense) behaves itself quite strange. When I start VS and open .fsx file, IntelliSense refuses to resolve even standard types/classes, and it doesn't underlines FAKE classes, it does nothing. But after some period of time and some manipulation over code IntelliSense starts working for standard types and underlines FAKE types.
Moreover, when I've created the similar code on my home workstation there were no problems, IntelliSense works as it should.
If you put the full path into the #r directive, you'll get full IntelliSense. The #I directive, while convenient, prevents IntelliSense from working properly though the code will run just fine. This is true for both loose scripts and those found in projects. Have a look at Tomas Petricek's [FSharp.AsyncExtensions](http://github.com/tpetricek/FSharp.AsyncExtensions] project.
No, that's not how it works. Does your code run? Intellisense is provided for assemblies referenced using #r.