I have a weird problem working in VisualStudio 2019, with cube .bim files.
I usually work on a model.bim, make some changes and then I check in the file... If someone else makes changes in model.bim I will always get this conflict:
Is there a way to avoid this?
Related
I have a large desktop application with 178 project in it.
I switched the domain on my PC and did a get from TFS to a different root path but most of the references are now broken.
They have a yellow warning next to them and no path.
The problem seems to be with both Nuget packages and system references. Strangely it seems to be intermittent, some package references and some system references are okay. The Dot Net Framework I am using is still in the same location
I have tried a package reinstall but that didn't work.
Has anyone come across this problem before who knows of any easy way to fix this that doesn’t involve deleting and adding them all again? Which does not work anyway.
Thanks in advance
Total red herring.
Turned out to be, I had not included the .nuget folder.
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 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.
We just set up TFS 11 for the first time. Running a gated check in, it succeeds but returns this message:
'srctool.exe' returned an unexpected exit code: '-1'. An error
occurred when opening a file "CustomDllName.dll": Assembly
"CustomDllName.dll" is not a valid .NET assembly and will be skipped
for analysis.
Well, it's right: that file is a legacy Visual Basic 6 DLL that we don't have much control over. It's included in the project for COM access to some of the methods.
Is there a way to instruct srctool.exe/TFS to skip that file when doing the inspection? Or another way to attack this?
Here is the solution that ultimately worked for me
A member of the TFS 11 team at Microsoft mentioned to me that the problem is due to a change in behavior that the Windows 8 team made to the srctool.exe tool.
By copying this file from the Windows 7 SDK (WinDBG) toolkit and overriding the one included in TFS 11 Beta, I was able to successfully run a build without any errors.
Is this a srctool.exe error from the shipped IndexSources activity? srctool.exe in this activity does one thing, which is to list the source files information in the pdb. I am not a srctool expert so I don't know why it fails in this case. I do know that srctool.exe has some behavioral changes in version 11, most of those are fixes from the previous version.
There is a workaround which requires udpating the build template. It is not very nice but it works. Srctool.exe is run (inside IndexSources activity) for each pdb file in the SymbolFiles collection. Now that you know which pdb fails, you can update the build template to add a RemoveFromCollection activity before the IndexSources activity that remove the troubled pdb from the SymbolFiles collection. This is by far the most straightforward workaround I can think of.
Alternatively, you can edit FindMatchingFiles activity's search pattern to exclude the pdb files you don't want to have sources indexed.
Based on the error message you got, it doesn't seem to be related to the known issue Ed mentioned. We fixed this issue for the next release, so if it's related, it should be fixed :-)
Let me know if you have any issue with VS11 Beta around the build templates.
Thanks.
I recently refactored some code, and a method the original Global.asax.cs file was depending on was no longer static. When I made changes to my Global.asax.cs code to fix the compilation problem, VisualStudio Development Server is still reporting the old problem. To make things more confusing, it's reporting the old problem with the new source code.
When I start up the development server I get the tell-tale error screen saying:
Method not found: 'System.Security.Principal.IPrincipal Example.Records.AuthenticationManager.GetPrincipleForUserName(System.String);
This original exception was located at line 54--which shouldn't matter to you, me or anyone else. However, it matters to Development Server. No matter what I change the code to, even completely commenting out the original code, I get the same error message. The only difference is the snippet of code it displays. It's currently pointing to a comment line.
So DevelopmentServer is seeing the old compiled code and VisualStudio is seeing the new code. I can't set the breakpoint because VisualStudio is telling me the source code is different from the original version.
How can I force DevelopmentServer to see the new code that works?
I have since found the real reason why this occurs, and it also affects the "Symbols not loaded for this class" problem when you try to debug your application. The problem has to do with the path to the DLLs. If your web application is part of a larger solution, and someone edits the solution configuration, Visual Studio will alter the build output path.
By default, the build output path for Debug is located in the ~\bin\ folder. This is so that Cassini can find the DLLs and the PDB files. When someone edits the master configuration and changes the architecture, VisualStudio will automatically update the target output directory to "~\bin{architecture}\Debug". You have to manually go into the properties for your project and set the output directory to "bin\" for debug again. Once you do that, it will work again.
--- Original Answer:
The only thing I could do to make it work was create a new project and copy all my code in. It's not a good answer, but its the best I could come up with. Same exact code ran like a champ. After going through the project file line by line, I could not find anything that would explain the behavior I was seeing.