Recently my team noticed that the output from compiling TypeScript files under VS 2013 differed from those compiled under VS 2015 in that the self-executing function parentheses style at the end of each function is slightly differently.
The difference looks like this:
This is annoying because we're constantly having to overwrite each other's changes or else having to revert the changes to all of the TypeScript compiled .js and .js.map files every time one of us builds.
Once our entire team updated to VS 2015, the issue went away, except for one person on our team who still sees these minor changes every time he builds on his machine. We are all running Visual Studio 2015 with TypeScript 1.8.6.0 installed.
We walked through the options under Project Properties -> TypeScript Build to verify everything is set the same, and they are. We also checked that everything is configured the same in Tools -> Options -> Text Editor -> TypeScript between the two machines.
The .csproj file is set up with <TypeScriptToolsVersion>1.8</TypeScriptToolsVersion>, which obviously is the same between both machines as well.
The only difference we can figure is that the guy who's machine compiles differently exported his VS 2013 settings and imported them into VS 2015, while the rest of us just started fresh with 2015, even though we've verified that all the relevant settings are the same.
Is there some hidden setting or configuration file somewhere that could cause the TypeScript compiler to behave differently that we're missing?
If you're using TypeScript there is no need to check-in .js or .js.map files. You also wouldn't want to check-in any typings you install through typings or tsd.
In general, you want to check-in the fewest number of files that will allow someone to run your application. You shouldn't really ever check-in the auto-generated files.
Related
WE have been having this issue with our Visual Studio 2019, certain files are automatically checked-out on all users when they load the company solution.
I am not sure why but it happens to all every user in the company and on all computers, as soon as you load the single solution that we have, files from Multiple projects are checked-out and they are always those 12 files,
When you compare these files with latest version / Server version you see no difference.
AutoCheckedout
BTW we are using Azure-DevOps Server but we had this issue since TFS 2017 Update 2
When Unbinding and rebinding / reloading Project
According to your description, it sounds like the solution isn't “bound” to the version control provider correctly.
From Visual Studio's main File menu, select File > Source Control > Advanced > Change Source Control
You'll see this dialog:
Make sure the server bindings are correct and that each solution/project is “connected”.
If everything looks like fine, then try to unbind any projects that are bound but not working correctly.
Bind all projects again that are now unbound. Which may do the trick.
Hope this helps.
I have a suite of C++ programs in Visual Studio 2012. I want to provide project and solution files for Visual Studio 2013 and 2015 as well (and later versions as they come), in the appropriate subfolders.
Is there a way to get Visual Studio to leave the old project and solution files, while adding the new ones?
No, it will convert the older version to a new one (or at least try to) on the first open attempt. But you can easily achieve the desired effect by manually creating 3 sets of project/solution files, each corresponding to different version.
Note though it's probably not a good idea to have a SW compatible with different compilers/IDEs. There are many differences between different compilers, the changes between VS2013 and VS2015 are especially extensive. Most likely you won't be able to immediately compile without errors on both of them. Some errors you'll be able to fix to satisfy both compilers but there are some changes that aren't backwards compatible, so you'll end up with multiple #ifdefs in the code which is not desirable from design and maintenance aspects. Also, maintaining multiple versions of project/solution files will be a pain in the ass.
My dev environment at work consists of a Visual Studio 2005 Solution with many sub-projects (by "project" I always mean VS project). Some of the projects build libraries which are used by other projects. By convention, a fair amount of test-related code ends up in header files which end up getting modified frequently. I've noticed that when I hit F7 to Build the solution, Visual Studio does not detect changes to header files that are in library projects. It will report that everything is up to date when it's not. To force it to rebuild the libary, I have to change (touch) one of the .c files in that particular project, or do Rebuild All which is quite slow.
Is there something I can change in the Solution or project settings to change this behavior so Build works as expected? I've actually gone so far as to hack together a script that "touches" one of the library .c files in a library when it detects an .h file has been updated, but there has got to be a VS solution to this.
Are the header files actually members of the library project - not just in an include file search path?
I have a project on SourceSafe that the team work with VS 2005.
I have installed VS2010 and like some features of this version.
Is there a way that I keep the project to day with SourceSafe, but however work locally with VS2010.
Say, I could not add new files to solution, but at least obtain, modify and archive the existing ones.
You can update all of the source files pretty safely unless you're adding code that is new since VS 2005. The main difference between the VS versions is in the project, and the solution files. What you can do is make your local project and solution files writable, and then use your source control to modify the source files. When all is said and done though you'll want to build it in 2005 (with the SourceSafe versions of the project and solution files) to make sure it all still works.
Also note that the conversion utility in Visual Studio that converts projects from previous VS versions is only intended to convert projects from the previous version. Since VS 2010's previous version is VS 2008 and not VS 2005 you may have to perform manual changes on your solution and project settings to get everything to build. The main thing that comes to mind is how global include directories are handled. If you have access to VS 2008 convert it to that first, and then to VS 2010.
Besides targetting the 2.0 framework VS2010 will still let you use new language features so you have to be careful.
And as Ben Burnett said, the sourcesafe binding doens't have to be a problem as long as you don't check out project and solution files. You can remove the read only flag from them so VS2010 can edit them, but they don't need be be checked into sourcesafe.
But I really wonder which feature you like so much about VS2010 that you want to restrict yourself to not be able to add, remove or rename files from your project.
For two of my VS 2005 C++ projects, VS wants to write to the .sln file when I build the projects. I have got a number of other VS 2005 C++ projects where this is not the case. It is a problem as due to the fact that we have ClearCase source control integrated with our VS 2005 installations and when we try and run an overnight build via batch files, the build pauses as a ClearCase check out dialog box is displayed.
Looking at what VS is changing in the .sln files, it is the second GUID on the project line.
Before building:
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "InterCommClientB", "InterCommClientB.vcproj", "{A2AF232A-7F27-4340-81D5-8ABFD10994D2}"
After building:
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "InterCommClientB", "InterCommClientB.vcproj", "{67BE85B7-3234-484E-88FB-4F0E42096583}"
Any help gratefully received. I am new to VS 2005, as we have only recently migrated from VC++ 6.0, so apologies if I have missed something obvious.
We are running VS 2005 Professional Edition, with SP1 installed.
Regards,
Greg.
I had similar problem. It seems that when converting projects from old versions of VS (like 6 or 2003) VS 2010 is not adding Project GUID to the .vcxproj file. Because of that when you open solution including such project VS will recreate GUID for such project, and will change .sln file but will not change .vcxproj file. So another time you open such solution the situation will be the same and the .sln file may change again.
See this: http://connect.microsoft.com/VisualStudio/feedback/details/586258/missing-projectguid-in-vcxproj-files
I am guessing here, but it looks like some changes have been made to the InterCommClientB project(project, not the files in the project). When this happens the sln is updated, in this case only the project GUID.
My best guess to resolve this issue would be to manually build the solution and then checkin the changes. This way the sln file won't change on build.
My second best guess is that you already made this changes at your computer and it is working fine, but you did not get lattest version on the pc where you do the night build .
This might be totally out there - but sometimes Visual Studio fails to check-in a Solution file when it's been modified and while the Solution is open in Visual Studio. Try closing Visual Studio, and only then committing the Solution file.
If it isn't that, there might be some other agency causing the Solution file to need to change the GUIDs its using. In one instance, I was using .NET tools from National Instruments, and they has a licensing scheme that would trigger that sort of action (modification of extraneous files for not good reason) whenever I went to do a rebuild.
Please take a careful look at the output from the build (in the log, or the output window) - you may find some further clues there!