I'm trying to run my build on visual studio but its says my .razor file starts with a lower case but it doesn't I changed it to an uppercase letter and also double checked my other .razor files and none of them start with a lower case number can some one tell me why?
tried restarting and saving all
Related
Short Version
I found myself losing alot of time renaming + including files in my Xamarin.Forms Projects because any change from Upercase to Lowercase (or vice versa) only in the files, will result in no change what so ever in the Project file, so i have a few questions:
Is there an option in Visual Studio that makes it take into account file renaming from Upercase to Lowercase? (See Edit Below)
What's the best way of changing alot of files from Upercase to Lowercase without delete/re-adding them?
Is renaming the file includes in the .csproj directly a Good Practice? if not, what is the best for this kind of scenarios?
Longer Version + Adicional Info
I had to include over 2000 images (Android + iOS and their respective sizes). So i started copying the files into the correct directory and include them in the Mobile Projects, the problem came when i already included the files in the project and some of the files had Uppercase letters that i haven't noticed before, so i made changes by hand to all the files, when i noticed that those changes weren't reflected in the Solution Explorer/Project File, i tried manually and got this error:
Edit: It seems this issue was apparently resolved in VS2019 arround v.16.1, but only if the file wasn't renamed externally. Since i did that i got this warning. This anwsers my first question.
And one solution that i found was renaming like: Foo.png > fooo.png > foo.png
But that would be exponentialy time-consuming by the number of files i had to edit, so i made this piece of code:
string filepath = #"C:\Users\(...)";
DirectoryInfo d = new DirectoryInfo(filepath);
foreach (var file in d.GetFiles("*.png", SearchOption.AllDirectories))
{
if (file.Name.Any(char.IsUpper))
{
File.Move(file.FullName, file.FullName.Replace(file.Name, file.Name.ToLower()));
}
}
What it does is basically create a new file but with Lowercase, that means i still have to Remove the old References and Include the new Files. This doesn't seem right since a simple rename would do.
What's my go to option here?
Windows as operating system is ascendant of the operating system where there was no difference in lower and uppercase. As such at today's state Windows treats the files with same letters as the same though technically it can remember and display lower and upper cases in file names.
Overall it means your request is not natural in Windows. Maybe someone can provide you with some hack, but if you want to resolve this problem quickly move your project to the Mac where this works differently at the operating system level, perform your operation in Visual Studio for Mac and then you can continue to use Windows if you prefer.
EDIT: Actually I can tell you one hack for Windows. First rename file to whatever you want (like add 1 at the end) and then rename it to the desired file name. It will work properly.
I had the same issue. In my case the files were in the .csproj (Project File) with lowercase name. Removing the affected lines from .csproj fixed the problem.
In Visual Studio 2019 -
Right click on the project name in Solution Explorer -> select "Edit Project File"
Find the offending file under ItemGroup, you can either remove the line or edit the filename. I have not had any side effects by removing the file as I know what I am doing, your mileage might differ.
Just incase cut and paste the delete or rename before hand in Notepad in case you want to go back, Ctrl-z works too :)
After I rename my file name (lower case to upper case) in VS Code, example card.cs to Card.cs, I got this error: The type of namespace could not be found are you missing a using directive or an assembly
How should I fix this issue?
Secondly, should I rename it at VS code locally, then push to my Git or should I rename it at Git and then pull it from Git?
Somehow after restart my VS Code, the error no more already. Solution is to rename in VS Code using 'rename' function and if file name is different I rename it using Git command
FWIW I had same issue, renamed a class lower case to uppercase by clicking Rename inside VS Code (Mac). Terminal shows a file name mismatch error displaying lower case name. Git Desktop showed lower case name. VS Code shows new name in files panel. My solution: Disable git extensions, delete the classes from my org, shut down git desktop and vs code. Restart vs code. Trying again it failed but only when I use cmd-p to deploy source for the visible window. If I right click on the filename in the files panel and deploy from there, it worked.
It also happens to me when changing uppercase to lowercase or vice versa. If it gets stuck like this and VS Code still requires the old name, it helps me to change the name to something else entirely and then rename it to what I want.
I'm making a translation program.
I have multiple project (s), which are class libraries, one for translating to English and Spanish.
They both have a file called irregulars.txt, which has "Copy if Newer" set, for irregular verbs but when I run the unit tests I get a name collision of both irregulars.txt. So, the Spanish and English irregular verbs are both the Spanish which makes it not work.
I am using Visual Studio Enterprise 2017 RC on Windows 10.
How can I stop this name collision?
The best approach would be not to hardcode the path of the files, but instead use some kind of configuration. For example, use a configuration file or command line parameters.
An ugly solution would be to use #if and compiler constants to change the source based on which DLL it is used in.
Since upgrading to VS 2015, my team has experienced random quirky things which I'm sure are being worked out at Microsoft right now. One pretty annoying one is that we seem to lose project references, especially after branching. I began to work on a new branch of our solution yesterday only to find out that types were unrecognized and namespace usings were being cited as unnecessary (because they were for the types that had suddenly become unrecognized).
The references in the project did not show any icons indicating a problem with the reference, but just to see if it would work, I removed and re-added a project reference, which caused its types to be recognized once more.
This, of course, updated the project file, so I looked to see what changes had been made. The only difference between the project that could not detect the reference and the one that now can is that the alpha characters in the GUID had been changed from lower case to upper case. For example:
Old, broken reference:
<ProjectReference Include="path/redacted">
<Project>{95d34b2e-2ceb-499e-ab9e-b644b0af710d}</Project>
<Name>Project.Name.Redacted</Name>
</ProjectReference>
New, fixed reference:
<ProjectReference Include="path/redacted">
<Project>{95D34B2E-2CEB-499E-AB9E-B644B0AF710D}</Project>
<Name>Project.Name.Redacted</Name>
</ProjectReference>
I'm looking for the reason this is happening and how I might fix it without having to manually remove and re-add references all over the place (and without having to convert all the project file GUIDs to upper case).
I should note that these "broken" references are not breaking the build, and that they only show up in the Error List as IntelliSense error, not build errors. So, the references aren't really broken, they've just broken IntelliSense (which is arguably worse?!).
TL;DR
Visual Studio isn't entirely consistent about how it assigns GUIDs to projects or how it specifies those GUIDs in project references. I was able to resolve the problem by using upper case GUIDs with braces for ProjectGuid elements and lower case with braces for Project elements (in references).
Background
We have a large solution (60+ C# projects), and were having regular issues with solution Rebuild as incorrect build order would cause failure to resolve referenced projects that had not yet been built (but should have been). Build Dependencies and Build Order appeared correct. MSBuild batch build worked fine, it was only a problem when rebuilding from Visual Studio.
Forcing all project GUIDs to upper case with braces and all project reference GUIDs to lower case with braces fixed the problem. This is usually how Visual Studio generates these GUIDs, but not always.
Doing some investigation in a brand new test solution, it turns out that:
Generated GUIDs for console application projects are upper case with braces.
Generated GUIDs for class library projects are initially lower case with no braces.
If a new project reference is added a class library project with a lower case GUID, then not only is the reference GUID added, but the project GUID is converted to upper case with braces.
If a copy of a class library project is made and then added to the solution then its GUID is replaced with a new one that uses upper case and braces. (But if a copy is made and its GUID manually removed, Visual Studio does not insert a replacement GUID into the .csproj file.)
Project references GUIDs are usually use lower case and braces, but somehow our project had accumulated a bunch of upper case GUID references.
GUIDs in the .sln always use upper case and braces.
I was able to fix our broken rebuild by replacing the reference GUIDs with either all upper case or all lower case -- it's something about the mix of upper and lower case that was giving Visual Studio problems (perhaps case-sensitive string keys in a dictionary somewhere?) Since Visual Studio normally adds references with lower case GUIDs, that is the option I chose to go with.
Regex Search & Replace
To fix this, I used Notepad++ regex-based search and replace in files to force all ProjectGuids in .csproj files to be upper case with braces (the default for console applications, and the style Visual Studio will apply after adding any project reference to the project):
Find what: (<ProjectGuid>)\{?([0-9a-f-]+)\}?(</ProjectGuid>)
Replace with: \1{\U\2}\E\3
Search in: *.csproj
Be sure to turn on regular expression search, and turn off match case. And don't search all files, or you may make changes you don't want, for example in *.xproj files, as noted by #AspNyc. (See this answer for additional info on use of regular expressions for changing case.)
I then replaced all references to projects to use lower case with braces (which is what Visual Studio usually does):
Find what: (<Project>)\{?([0-9a-f-]+)\}?(</Project>)
Replace with: \1{\L\2}\E\3
Search in: *.csproj
Having made these changes, Visual Studio solution rebuild now works reliably. (At least until next time rogue upper case reference GUIDs sneak into our project.)
I suffered a similar issue when updating VS2017 v15.7 to v15.9.
The answer for me was to close down VS, clear out the hidden .vs folder in my solution's root directory and restart VS.
There's a bug in the projectsystem it seems. This powershell will loop over projects and make all references upper case:
#FixGuids
get-childitem -recurse | ?{ #('.sln', '.csproj', '.vbproj') -contains $_.Extension } | %{
[regex]::Replace((gc -raw $_.FullName), '[{(]?[0-9A-Fa-f]{8}[-]?([0-9A-Fa-f]{4}[-]?){3}[0-9A-Fa-f]{12}[)}]?', { return ([string]$args[0]).ToUpperInvariant() }) |
Out-File $_.FullName -Encoding "UTF8
}
It's quite simplistic. If you rely on guids in your projects for something other than references, you may want to turn it into something more intelligent.
In order to use the answer in a git hook, I had to convert it to sed's regex syntax:
sed -r "s/(<Project>\{?)([0-9A-F-]+)(\}?<\/Project>)/\1\L\2\E\3/g" sample.csproj
Maybe someone finds this useful.
Today in visual studio 2019 (16.2.2) I was encountering build system issues where projects were being unnecessarily (and repeatedly) rebuilt whenever I initiated the building of my solution.
(None of the usual steps resolved the build issues, eg deleting the ".vs" folder, or deleting "bin" and "obj" directories, etc).
At first it appeared to be related to the character-casing of guids, because I was able to get the problem to go away by editing the guids and saving the project. However that was a red-herring ... I was unwittingly fixing the problem by changing the timestamps of all my csproj files. The build system seemed a lot happier after those timestamps were updated, and it stopped the annoying behavior (continuously attempting to rebuild projects that had already been built.)
The character casing of the guids didn't end up being the problem at all. As far as I can tell, VS 2019 is ok with both upper- and lower-case guids. They can even mismatch the source project, based on my experimentation (eg. the original source project can use uppercase and referencing projects can use lowercase).
If it is helpful to anyone, below is a powershell that will let you adjust the write-time of all csproj files under a path. This will be another trick I use whenever the msbuild system is misbehaving in visual studio.
$datenow = get-date
$files = Get-ChildItem -path "C:\Data\Workspaces\LumberTrack\" -recurse | where { $_.PSIsContainer -eq $false}
foreach ($file in $files)
{
if ($file.Extension -eq ".csproj")
{
Set-ItemProperty $file.FullName LastWriteTime $datenow
Write-Output $file.FullName
}
}
}
Since upgrading to VS 2015, my team has experienced random quirky things which I'm sure are being worked out at Microsoft right now. One pretty annoying one is that we seem to lose project references, especially after branching. I began to work on a new branch of our solution yesterday only to find out that types were unrecognized and namespace usings were being cited as unnecessary (because they were for the types that had suddenly become unrecognized).
The references in the project did not show any icons indicating a problem with the reference, but just to see if it would work, I removed and re-added a project reference, which caused its types to be recognized once more.
This, of course, updated the project file, so I looked to see what changes had been made. The only difference between the project that could not detect the reference and the one that now can is that the alpha characters in the GUID had been changed from lower case to upper case. For example:
Old, broken reference:
<ProjectReference Include="path/redacted">
<Project>{95d34b2e-2ceb-499e-ab9e-b644b0af710d}</Project>
<Name>Project.Name.Redacted</Name>
</ProjectReference>
New, fixed reference:
<ProjectReference Include="path/redacted">
<Project>{95D34B2E-2CEB-499E-AB9E-B644B0AF710D}</Project>
<Name>Project.Name.Redacted</Name>
</ProjectReference>
I'm looking for the reason this is happening and how I might fix it without having to manually remove and re-add references all over the place (and without having to convert all the project file GUIDs to upper case).
I should note that these "broken" references are not breaking the build, and that they only show up in the Error List as IntelliSense error, not build errors. So, the references aren't really broken, they've just broken IntelliSense (which is arguably worse?!).
TL;DR
Visual Studio isn't entirely consistent about how it assigns GUIDs to projects or how it specifies those GUIDs in project references. I was able to resolve the problem by using upper case GUIDs with braces for ProjectGuid elements and lower case with braces for Project elements (in references).
Background
We have a large solution (60+ C# projects), and were having regular issues with solution Rebuild as incorrect build order would cause failure to resolve referenced projects that had not yet been built (but should have been). Build Dependencies and Build Order appeared correct. MSBuild batch build worked fine, it was only a problem when rebuilding from Visual Studio.
Forcing all project GUIDs to upper case with braces and all project reference GUIDs to lower case with braces fixed the problem. This is usually how Visual Studio generates these GUIDs, but not always.
Doing some investigation in a brand new test solution, it turns out that:
Generated GUIDs for console application projects are upper case with braces.
Generated GUIDs for class library projects are initially lower case with no braces.
If a new project reference is added a class library project with a lower case GUID, then not only is the reference GUID added, but the project GUID is converted to upper case with braces.
If a copy of a class library project is made and then added to the solution then its GUID is replaced with a new one that uses upper case and braces. (But if a copy is made and its GUID manually removed, Visual Studio does not insert a replacement GUID into the .csproj file.)
Project references GUIDs are usually use lower case and braces, but somehow our project had accumulated a bunch of upper case GUID references.
GUIDs in the .sln always use upper case and braces.
I was able to fix our broken rebuild by replacing the reference GUIDs with either all upper case or all lower case -- it's something about the mix of upper and lower case that was giving Visual Studio problems (perhaps case-sensitive string keys in a dictionary somewhere?) Since Visual Studio normally adds references with lower case GUIDs, that is the option I chose to go with.
Regex Search & Replace
To fix this, I used Notepad++ regex-based search and replace in files to force all ProjectGuids in .csproj files to be upper case with braces (the default for console applications, and the style Visual Studio will apply after adding any project reference to the project):
Find what: (<ProjectGuid>)\{?([0-9a-f-]+)\}?(</ProjectGuid>)
Replace with: \1{\U\2}\E\3
Search in: *.csproj
Be sure to turn on regular expression search, and turn off match case. And don't search all files, or you may make changes you don't want, for example in *.xproj files, as noted by #AspNyc. (See this answer for additional info on use of regular expressions for changing case.)
I then replaced all references to projects to use lower case with braces (which is what Visual Studio usually does):
Find what: (<Project>)\{?([0-9a-f-]+)\}?(</Project>)
Replace with: \1{\L\2}\E\3
Search in: *.csproj
Having made these changes, Visual Studio solution rebuild now works reliably. (At least until next time rogue upper case reference GUIDs sneak into our project.)
I suffered a similar issue when updating VS2017 v15.7 to v15.9.
The answer for me was to close down VS, clear out the hidden .vs folder in my solution's root directory and restart VS.
There's a bug in the projectsystem it seems. This powershell will loop over projects and make all references upper case:
#FixGuids
get-childitem -recurse | ?{ #('.sln', '.csproj', '.vbproj') -contains $_.Extension } | %{
[regex]::Replace((gc -raw $_.FullName), '[{(]?[0-9A-Fa-f]{8}[-]?([0-9A-Fa-f]{4}[-]?){3}[0-9A-Fa-f]{12}[)}]?', { return ([string]$args[0]).ToUpperInvariant() }) |
Out-File $_.FullName -Encoding "UTF8
}
It's quite simplistic. If you rely on guids in your projects for something other than references, you may want to turn it into something more intelligent.
In order to use the answer in a git hook, I had to convert it to sed's regex syntax:
sed -r "s/(<Project>\{?)([0-9A-F-]+)(\}?<\/Project>)/\1\L\2\E\3/g" sample.csproj
Maybe someone finds this useful.
Today in visual studio 2019 (16.2.2) I was encountering build system issues where projects were being unnecessarily (and repeatedly) rebuilt whenever I initiated the building of my solution.
(None of the usual steps resolved the build issues, eg deleting the ".vs" folder, or deleting "bin" and "obj" directories, etc).
At first it appeared to be related to the character-casing of guids, because I was able to get the problem to go away by editing the guids and saving the project. However that was a red-herring ... I was unwittingly fixing the problem by changing the timestamps of all my csproj files. The build system seemed a lot happier after those timestamps were updated, and it stopped the annoying behavior (continuously attempting to rebuild projects that had already been built.)
The character casing of the guids didn't end up being the problem at all. As far as I can tell, VS 2019 is ok with both upper- and lower-case guids. They can even mismatch the source project, based on my experimentation (eg. the original source project can use uppercase and referencing projects can use lowercase).
If it is helpful to anyone, below is a powershell that will let you adjust the write-time of all csproj files under a path. This will be another trick I use whenever the msbuild system is misbehaving in visual studio.
$datenow = get-date
$files = Get-ChildItem -path "C:\Data\Workspaces\LumberTrack\" -recurse | where { $_.PSIsContainer -eq $false}
foreach ($file in $files)
{
if ($file.Extension -eq ".csproj")
{
Set-ItemProperty $file.FullName LastWriteTime $datenow
Write-Output $file.FullName
}
}
}