I have a small-ish MVC4 web app using TypeScript for the clientside (~40 .ts files).
When I upgraded TS to 0.9.1.1, I now see 100+ errors in lib.d.ts appearing the error list in Visual Studio 2012.
The problem is unavoidable (all members of our team got the same thing when they upgraded), but literally impossible to reliably reproduce. Some behaviours:
The errors will not appear right away, only after a certain (seemingly random) amount of time.
They will usually be triggered on saving a file.
They are things like:
"All named properties must be subtypes of string indexer type 'any'"
Removing any .ts file from the project or restarting VS will make them go away for a time, but they will always come back.
The compiler still runs, and all .js files are generated correctly.
I have tried setting up a new empty project, in both VS2012 and VS2013 RC, then started adding our TS classes one by one. At some point, the errors will appear, but retracing steps has proved completely fruitless in identifying what might kick it off. However, it does seem to only happen as you approach 15-20 .ts files.
I'm at my wits end here.
PS. In the error list, the under the "Project" column, it often names a particular file, rather than a project. Quite often it's a definitions file, e.g. underscore.d.ts. Why would this be named as a Project?
EDIT:
I've managed to recreate this with a single .ts file and a handful of definition files.
App.ts
module Application {
export class Main {
constructor(options?) {
}
}
}
In addition to most recent versions of:
backbone.d.ts
jquery.d.ts
underscore.d.ts
backbone.relational.d.ts
I made many rapid changes and saves to App.ts to reproduce i.e. ~10 in 5 seconds. Could this suggest a file permissions error?
Go to visualstudiogallery
and make sure you have the latest version of typescript installed.
It seems that it is because of optimisations done in typescript language services. Visual studio tries to partially update the information for analysis, but once analysis lags, behind update commands this happens.
A temp fix is to cut the entire contents of the file, and paste them back, this gives the language service a fresh view of the file.
Related
While switching over to a new computer I installed the latest version of Visual Studio 2019 (v16.3.5). As a result when I load the project and try to update the models from the database it updates every single model by changing indents and adding extra line breaks and spaces in places. As a result in git every single model shows up as being changed when in reality nothing was actually changed other than spacing. I tried to look for a setting which could change this but had no luck. Restarted VS a couple of times and tried to right click on edmx file and "Run Custom Tool" but no luck.
I have several coworkers who are running 16.1.3 and have no issues, so it looks like it could be something that changed/broke in a new release. I have read via forums about other users having issues with VS2019 and edmx related tasks but haven't encountered this exact problem yet on the web.
UPDATE: It looks like if I downgrade to 16.1.3 I still see the issue. It is the same version my coworkers are on and don't see it. Could this be some kind of setting?
Found a link finally where somebody had the same issue. It actually turned out to be line endings. I had to open the 2 .tt files I had in notepad++ and convert to windows and save. Once I did that I was able to update without all models changing.
Edmx generate model file with blank lines
I have a MVC5 project that is currently set on the "Release Configuration" and it works 100%. However, as soon as I switch the project configuration from Release to Debug, then everything goes wrong... even if I switch it back to Release mode, everything is still broken. Only way I can get the project working again is to restore from a backup.
Here are what is happening.
Firstly, when running the project, I get the following error:
BC30451: 'ViewData' is not declared. It may be inaccessible due to its
protection level.
If I open any view in the project with Visual Studio 2013, I can see that all sorts of things are marked as errors like ViewData, Html, Url, etc.
When referring to #Html or #ViewData in the view, it normally refers to the .Html and .ViewData properties of the view's base class (WebViewPage). However, if I start typing "#Html." in any of the views, I can see in the autocomplete that it is referring to the System.Web.Webpages.Html namespace instead of the WebViewPage.Html property. It is as-if the view isn't inheriting from the System.Web.Mvc.WebViewPage class.
Any guidance as to where I can start looking to get this fixed or why this is happening?
Edit:
So since nobody responded, I went through the long way. I created a brand new MVC5 project, added all the packages via Nuget and then simply copied all my files over from the old project to the new one and now it works.
Does anybody have any idea what the heck could be causing this? I don't want to go through all this trouble again in the future if the project again suddenly decides to stop working.
Ok, I think I've found part of the cause here. Thing is, since the original code is valid (it compiles correctly and intellisense picks it up) and the code used to work and then all of a sudden, one day after compiling, it just stops working.
Anyway, in the view, when specifying the ModelType, if you don't use the full name, this error can occur or occurs eventually.
For example, using:
#ModelType Models.SomeNamespace.SomeClass
will cause the error (even though the Root Namespace for the project is "MyProject") and it can be fixed by simply specifying the full namespace and class name.
#ModelType MyProject.Models.SomeNamespace.SomeClass
It's possible that a debug assembly is locked. Can close Visual Studio, search and delete for all bin folders in the solution directory. Then open and rebuild.
The other options is to go into the MVC project properties and compare the two build configurations. Are you targeting a different .NET framework between Release and Debug? 32 bit vs 64 bit? etc?
Looks like some MVC assemblies are corrupted.
Have you checked your referenced assemblies for some errors?
Try also cleaning all the .NET internal cache. More in this stackoverflow topic: Could not load file or assembly ... The parameter is incorrect
In my case imported ViewModel class name was incorrect, correcting it fixed the issue.
I've got a group project built in Delphi XE2 that has 3 projects that always build to the wrong folder for one option set. (I've got 4 configurations under Release and Debug, one for our software configurations and one for FastMM and it's only the debug one that I want to use for debugging that always goes in to the wrong folder. Compiling the project even says it's building to the correct folder, but the DLL always winds up in a different one which I only used once when I was unit testing the code outside of the main project.
I've deleted every associated file, .identcache, .res, .tvsproj (whatever that was) and nothing changed. One very strange thing I noticed is that I copied one of the projects to configure the second one and mimics the behavior of the one it was copied from and I never even unit tested that one, so it never had that output path configured for it.
Obviously this makes it pretty annoying to debug, I have to copy files in to the correct folder just to do that (I was kind of astonished when it actually worked, because I thought Delphi might expect to find the files in it's output path, but oh well, those things are magic)
Let me know if I can post anything to help, I don't really know what's necessary, I checked the registry for the output path that it is getting built do and found nothing that I thought was of any consequence (nothing related to these projects).
One thing I did notice was, because I copied the original project into another project (they're plugins to the same part of the main program) it has the same and when I try using it in the "Build Group" it automatically selects both projects. That's one mystery solved, but is probably a red herring?
OK so as usually happens, after 3 years of suffering with this when I finally ask the questions I'm lead straight to the answer it appears as if RAD Studio is lying to us. The configuration shows this:
but the dproj had this:
in it.
there were two conditions for cfg_3 and only the last one showed up in RAD Studio, well for some odd reason the build path was taken from the first one (even though it's specified in both). So, removing the wrong one (the first one) fixed the problem and things are now building to the correct folder.
I had imported the Utils option set when I was testing the library, but when I incorporated the program in to the main program, I removed it. Somehow it didn't find it's way completely out of the dproj and I guess (not sure why) but it seems like the other library got messed up because it shared a GUID.
I'm having some kind of problem with my project that me and my friend is working on. When I try to open the project that I've been working on it gives me an error message saying that "one or more lines were too long and have been truncated" and thus I can't see my code or GUI. When my friend opens the project on his computer (The project is on dropbox so it's the same file) there's no problem at all. I've googled but couldn't find anything. I just did a repair of RAD Studio but no luck. We have 2 forms and a unit that we use, the unit and the mainform isn't working for me but the second form is no problem.
Thanks!
Make a copy of your project directory.
Search your harddisk for XXXX.pas and XXXX.dfm
Hopefully there will be some temperary files that match - like "mylostform.dfm.~1307~" . copy the newest to your project directory, and rename them to "mylostform.dfm" and "mylostform.pas".
Kind regards,
Geir Bratlie
From the comments, you have Dropbox, and the Restore functionality is available, but using it would cost you a week's worth of work.
If I was in that situation, here's what I would do:
Copy the current file to somewhere else (My Documents, for example).
Use Dropbox Restore to get the old version that works.
Make a copy of this, because you're going to be modifying it
Ensure that you can open it in the IDE.
Use Beyond Compare to open the two files side-by-side. (If you don't have this, you really should!)
If they're completely different from each other, you have a serious problem. If not, you'll see the changes you've made. Start copying changes one at a time, and after each change, save and try to open it in the IDE.
At some point, you won't be able to. That's where your problem lies. Now you can fix it!
I've just written the first version of a workflow activity that will run Resharper's Code Issues on the projects and parse the output to display the issues as build warnings and errors.
At first, I was going to just call Resharper's command line and parse the resulting xml manually. After fiddling with the dlls in Resharper's SDK (through disassembly mostly), I found a way to parse the results using it's own public classes, which I figured was a much more elegant and safe way to do this.
The first problem I have is that that nuget package is absolutely huge. There is 140mb of files in there, which to me is absurd for a single, unpartitioned package. There seems to be such heavy coupling between them that by using just a few model classes and the parser class, I have to drag a dozen or so of those dlls along, some of them which seemingly have nothing to do with the main dlls I need. This is not a show stopper though, I'm struggling with something else now:
In the end, I managed to track down the dependencies I needed to 41 assemblies (which is, again, insane, but alas). Initially, I tried removing everything and adding the missing references one by one, but this turned out to be unreliable, still missing some indirect references, even after compiling successfully. Then, I decided to code a small console application to find all referenced assemblies in the main Resharper assemblies I used, which gave me the 41 references I mentioned. This is the code I used to find every dependency.
Since these are custom activities we are talking about, I decided to create a unit test project to validate them. Using these 41 references only, everything works correctly.
When I added the activity to the build workflow though, and pointed the build controller to the source control folder containing the required assemblies, every time I schedule a build, the process fails stating that I need one extra dll from Resharper's SDK. For example, this is the first one it asks:
Could not load file or assembly 'AsyncBridge.Net35, PublicKeyToken=b3b1c0202c0d6a87' or one of its dependencies. The system cannot find the file specified. (type FileNotFoundException)
When I add this specific assembly to the TFS folder, I get another similar error for another dll, and this keeps going on and on.
What I wanted to know is how can I know exactly which assemblies a workflow XAML will need in order to run correctly? My custom activity dll has two specific CodeActivities and a XAML only activity that uses these two. This XAML acticity is what I'm directly using in the modified workflow template.
I see that besides the references in my project, the XAML activity also contains a TextExpression.ReferencesForImplementation section, with some assembly names. I've run my dependency finder program on those dependencies too, and the results are the same 41 assemblies already at the TFS folder.
Meanwhile I'll go with having the whole SDK into the custom assemblies folder, but I would really like to avoid this in the future since it has such an enormous amount of unneeded and big dlls in there.
First, we have request for our command line tool to support workflow activity and we decided to implement just plain MsBuild task which is universal and works in TFS too. Task and targets files are included in ReSharper CLT 8.2.
Second, if you still want to implement workflow activity it's pretty easy to do with new API in CLT, designed specially for custom processing of found issues - http://confluence.jetbrains.com/display/NETCOM/Custom+InspectCode+Issue+Logger.
And last, but not least, you do not need to put in VCS binaries of ReSharper SDK package.
Use NuGet's restore package functionality.
If you have any other questions I'll be glad to answer them.
A custom activity is being load and run by .NET CLR like any other .NET program. If the stack trace reports a missing file, then it's required by the CLR and you can't change this fact without refactoring your code.
Having an entire SDK references in the custom assembly folder doesn't make sense. I would prefer GAC deployment over huge binaries folder in the source control. Or maybe consider having these activities running an pre\post build scripts in MSBuild or PowerShell.