Visual Studio 2019 (v16.3.5) - Updating EDMX File Changes Spacing and Indents On All Models - visual-studio-2019

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

Related

Visual Studio won't show added files in the solution explorer

Why would VS2019 (with VisualGdb) refuse to show added files the solution explorer?
I found some workaround, i will post as an answer. But i'm still quite interested in the explanation of the underlying problem.
Additional info: opening the project file (.vcxproj) shows that the files are actually added to the project, only they are "invisible" in the project explorer.
I'm not sure, if this issue is VS-related or VisualGDB-related, or even layer-8-related, but hopefully this answer will help some people anyway.
So after trying many things not leading to success, i found this workaround:
In the project file (.vcxproj), i actually found entries for theses "invisible" files, and after deleting them and re-opening VS, i added these files again in the soluton explorer. Only this time, they correctly showed up in the solution explorer.
Weird: a compare tool showed not the slightest change in the project file, so there got to be some underlying issue.

VS 2019 Configuration Manager shows blank configurations

Below is the Xamarin Forms solution but I have witnessed the same in WPF solution too. App.iOS project has blank configurations.
What's worse, you are not able to Add New ones by scrolling down and pressing <New...> - It does nothing. If you try to <Edit...> and remove/rename the blank ones, you get an error "The operation could not be completed".
I would like to remove blank rows, and be able to add new configurations using the <New...> button.
What I've tried:
Cleaning and rebuilding project
Rebooting Visual studio and PC
Tempering with App.iOS.csproj file, no blank data in there, nothing looked wrong to me.
So maybe this will help you. I had the same issue on my solution today and found your post.
I tried messing around with the sln file manually without luck.
My solution:
Since my project was x86 only I ended up clicking the edit in the Active solutions platform: dropdown.
I removed the items x64 and Any CPU. Then I went to each project and checked if it still had those two entries. Some did and I removed them. To my surprise when I then clicked the dropdown for one of the projects that had blank entries they were gone and so was the ones for the second project that had the blank entries too. Hopefully this will work for you.

Delphi consistently building DLLs to the wrong directory

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.

Can't open project: "One or more lines were too long and have been truncated"

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!

100+ errors in lib.d.ts with TypeScript in Visual Studio

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.

Resources