The indentation of our web .csproj file is being changed to spaces or tabs, depending on the particular installation/user/machine doing the work. For two of us, VS 2019 will force it to indent of 2 spaces (which we want). For the other two developers, their VS will change it to tab indent whenever adding a new file to the project.
Our tab settings are the same for:
C# = Smart / Tab Size 4 / Insert spaces
XML = Smart / Tab size 4 / Keep tabs
We could not find a setting for .csproj files. The behaviour of VS does not seem to match any of the settings we checked.
Is there another item in Tools / Options / Text Editor or elsewhere that governs this?
The reason this matters is, whenever we merge a changed csproj back into the common branch, if there is a difference in indenting, git doubles the size of the file, including both versions. Git doesn't recognise the lines are really the same apart from leading whitespace.
"Tabs to spaces" is a personal preference.
NOT stored in the csproj file(which is committed to get project), but (a) defaulting from your VS preferences; or (b, most likely) overridden in project specific 'Project Preferences' file (the extension eludes me).
Private preferences shouldn't but committed to the git project, and are typically ignored in the git.ignore file.
But, if that for has been stored with your project, it will now be be downloaded as 'read-only' in any pull, overriding any personal changed you've made.
The " .suo" file rings a bell. Add to git.ignore, and delete from the stored GIT project.
It was bothering me as well. Especially when the original csproj file has 2 spaces and any reformatting change it to 4.
I prefer 2 spaces for csproj and you can do it with a help of EditorConfig on a Solution or Project level. If you do it on the Solution level, add the .editorconfig file to your solution folder with the following content:
# All files
[*]
indent_style = space
[*.csproj]
tab_size = 2
You can find more information in Microsoft Documentation for EditorConfig
Related
Is there a file somewhere that I can use to do massive changes to the context menu in an easier fashion?
The GUI:
gives me no way to move a command from one menu to another, nor does it let me see what the command actually is (in order to add that same exact command to another menu), thus I don't have much to work with.
And thus I am seeking a file (or a gigantic registry key? ugh.) that I can edit somewhere else where I have more powerful tools. (my VS version is Enterprise 2017 if that matters)
You can find the defaults at C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Profiles, with a general settings and some language-specific overrides. There's an additional override in IDE\VC\Profiles as well.
In my case, I wanted to move 'Start new instance" on a Project into the top-level context menu. So I:
Made a copy of CurrentSettings.vssettings
Added a new command where I wanted it (via the Tools > Customize... GUI)
Found the command I wanted to clone and moved it up one
Closed VS (it saves on exit)
Compared the two files to find the diffs (use your favorite tool.) You'll find them under Category[#name="Environment_CommandBars"]\CommandBars\UserCustomizations as add remove and modify entries
Took the Cmd attribute from the moved entry and pasted it over the added one (it was Cmd="{1496A755-94DE-11D0-8C3F-00C04FC2AAE2}:00000164" for me, to save interested parties a few steps)
Undid the move to retain only the added entry
I wasn't able to find a command entry for this anywhere in the defaults, so had to figure it out the hard way.
I have just upgraded to VS2015 and I am experiencing an issue I have not seen before. Using an existing solution under source control, I am able to modify files and they get picked up as pending changes ready to check in to TFS.
However, I add a new file (Test.cs as an example in this screenshot), it is not picked up as a new file.
I am required to right-click it and click "Add files to Source Control"
This has never been an issue before. I would like everything I add as a new file to be picked up as a pending change. How can I make this happen? I have not seen this before in previous Visual Studio versions.
I can confirm that this issue is the same on another machine. Also, the new file is not picked up in "Promote Candidate Changes" either.
If I then click "Add file to Source Control", I get this message.
"The selected file is ignored. Add it to source control anyway?"
My .tfignore file just has a directive to ignore packages, so I don't think this file is the problem.
How can I get my settings back on track?
UPDATE:
I have noticed that this only happens to the "Release" branch of my workspace. All other branches behave as expected. Furthermore, if I then take a branch "Release" and call it "Release1", the issue goes away entirely!
Do branches with the specific name "Release" take on any special functionality in TFS?
Folders called Release and their contents is automatically excluded from TFS (along with Debug and lots of file types). You can override this for particular folders by creating a .tfignore file, as detailed in the "Customize which files are ignored by version control" section of this link
Customize which files are ignored by version control
By default certain types of files (for example, .dll files) are
ignored by version control. As a result:
When you add ignored files to folders that are mapped in a local
workspace, they do not appear in the Pending Changes page in Team
Explorer.
When you try to add ignored files using the Add to Source Control
dialog box (for example by dragging them into Source Control
Explorer), they automatically appear in the Excluded items tab.
You can configure which kinds of files are ignored by placing text
file called .tfignore in the folder where you want rules to apply. The
effects of the .tfignore file are recursive. However, you can create
.tfignore files in sub-folders to override the effects of a .tfignore
file in a parent folder.
.tfignore file rules
The following rules apply to a .tfignore file:
# begins a comment line
The * and ? wildcards are supported.
A filespec is recursive unless prefixed by the \ character.
! negates a filespec (files that match the pattern are not ignored)
.tfignore file example
Ignore .cpp files in the ProjA sub-folder and all its subfolders ProjA*.cpp
Ignore .txt files in this folder *.txt
Ignore .xml files in this folder and all its sub-folders
*.xml
Ignore all files in the Temp sub-folder \Temp
Do not ignore .dll files in this folder nor in any of its sub-folders !*.dll
We were also experiencing this issue but in our case it was because we had folders that ended in ".Lib". Figured it out from this SO question: Visual Studio 2015. Files not added to TFS
We have the same issue because of a branch called 'Release'. But the issue is only at Visual Studio 2015 Update 3. Using Visual Studio 2015 Update 2, everything is ok. So Visual Studio Update 3 must have been changed its behaviour. It would be useful to return to its old behaviour.
Add a .tfignore file to the release folder containing the extensions you want it to not ignore:
!*.vb
I tried adding this to the .tfignore that existed in my solution folder and it didn't help. It only worked when I added one to the parent release folder.
..\Release
..\Release\.tfignore <-- this one
..\Release\SolutionA\
..\Release\SolutionA\.tfignore
msdn thread on the subject
I have a set of fonts inside my Visual Studio solution, these were added using the 'Add existing items' option in Solution Explorer. There has now been an update to the fonts and I'd like to replace the original files with the new ones.
How do I replace these existing items in my solution? Is it as easy as hitting 'Add existing items' again and Visual Studio will overwrite the files, or do I have to do something different?
If you are using a local workspace just replace the files with the new ones in the disk and you will see them in pending changes available for checkin.
If you are using a remote workspace (this is the case if all the files in the workspace are read only) you have to check out the files first, replace the files with the new ones and then you can check the changes in.
Bear in mind that binary files should be checked out exclusively to avoid other users from modifying the files, otherwise, in case of conflicts (two users editing simultaneously) a merge will probably not be possible.
You can just override the files in the files system. If the name of the file is the same, visual studio will use the new ones. If the file names are different you should you should remove the old ones by just marking them in solution explorer and pressing delete. Then add the new ones by using Add existing items.
If I create an empty SharePoint 2010 project in VS2010, then add features to the project, the features are named Feature1.feature and Feature2.feature, etc, etc. I'd like to give these features a sensible name in VS2010, for example MyCustomFeature.feature and MyOtherCustomFeature.feature, but I can't work out how to do this. VS2010 provides "right-click, rename" support, but it does not work for me.
Can anyone help me out?
I found the answer to my question. The environment I am working in has a tilde character at the start of all Active Directory login names, for example '~abc'. The default file save location in Visual Studio is therefore 'C:\Users\~abc\Documents\Visual Studio 2010\Projects'.
The Sharepoint tools in VS2010 do not like that tilde character. The tilde prevents you from renaming any of the "FeatureX" nodes under the Features folder. VS2010 or the event log do not report an error, the rename just fails. As soon as you move the project to C:\MyTestProject, feature rename works just fine.
Additionally, a user cannot create a My Site if the login name contains the tilde character:
Event ID 5187: My Site creation failure for user 'DOMAIN\~abc' for
site url 'http://[webapp]/personal/~abc'. The exception was:
Microsoft.Office.Server.UserProfiles.PersonalSiteCreateException: A
failure was encountered while attempting to create the site. --->
Microsoft.SharePoint.SPException: "/personal/~abc" contains illegal
character '~'.
KB905231 warns against having a tilde in Active Directory group names, but not login names:
http://support.microsoft.com/default.aspx?scid=kb;en-us;905231.
My advice - avoid the tilde!
Adding to the list: My project had a comma in the path, VS wasn't allowing me to rename the feature. I took off the comma and was able to rename the feature. It seems SharePoint Tools doesn't like anything "unusual" on the project path. Thanks to PeteL and Yuri that pointed me to the solution.
I had the same issue with VS 2010 and SharePoint tools, looking to this theme I decide to create a new project without any illegal chars in path, after several experiments I found out that my actual path contained '!' symbol, in root folder name - 'd:!Projects' that doesn't allow to change the feature name. Also both '_' and '.' work fine in folder names.
Works fine for me. Do you have Source Control? I had some issues where I was using SVN and I couldn't rename a file I've just created because SVN was telling me I had uncommited changes. After commiting, renaming worked fine.
It's definitely possible.
I use SharePoint 2010 projects in VS2010 with TFS and have some sort of hack to rename newly added feature with default name "Feature" to the project.
1) Exclude feature from the project - it will disappear in the project tree but will still visible if you click "Show All Files"
2) Rename file "Feature1.feature" and its parent folder via the properties window or right click on the feature file and select "Rename" option. Make sure that file "Feature1.feature" and its parent folder have the same names e.g. "ListsAndContentTypes.feature" for feature file
and "ListsAndContentTypes" for the parent folder
3) Right click on the parent feature folder (in example above "ListsAndContentTypes" ) and click "Include in project"
Now the feature file have appropriate name.
4) Make sure that it is included in the package - check the "Package" project item.
Hope this helps.
I've run into a problem with VS2010 (it also exists in the latest version, SP1 (10.0.40219.1)):
Add an existing Word file to the "Solution Items" and check this new file in.
Check the file out for editing
Double click on the file and edit it in Word (just make some minor changes)
Save the file (CTRL-S)
Now the file is removed from the "Solution Items" in Visual Studio (you may have to repeat the editing and saving a couple of times)
Update: I'm using Visual SourceSafe 2005.
Despite my research efforts I haven't really found anything on this issue apart from this Microsoft page, and I'd like to know whether there is a way to prevent this problem from happening.
Any ideas are more than welcome, thanks in advance.
G.
After further investigation I think I found the reason behind this behaviour and a workaround.
Please also note that the behaviour described in the original question only occurs for files that are added directly underneath a solution or to a folder that is directly underneath a solution.
The reason
I'm not sure whether the following is 100% correct, but the main point is how Word (and probably other MS Office apps as well) saves an existing file:
Save the current version of the file to a temporary file
Rename the original file so it can be used later in case something goes wrong
Copy the temporary file to the location of the original file, using the original file's name
Delete the original file (that was renamed in step 2)
Visual Studio picks up that the file doesn't exist (for a very short time though) and removes it from its tree and the .sln file. This can also be reproduced by manually adding any kind of file, checking it out (if not checked out), renaming it to a different name and then back to its original name => file is no longer shown in Visual Studio.
The workaround
I've created an empty project template following the steps on Microsoft's site. I also set the output to "Class Library" so that the project would compile even if no static main method exists. This template can be used to add a "Documentation" project to an existing solution. Underneath this project you can add files and edit them as you wish, as Visual Studio behaves differently and does not remove the file when it is saved in this constellation.
Obviously this approach is still not very satisfying or elegant, but I hope that it may be helpful for others who might run into the same problem.
G.
I've run into the same issue. I simply undo changes for the solution after I've closed the document file and the solution files will be as they originally were before your document changes.