some background: I work on Windows 10 and have a C# project that contains some .cs files like Foo.cs, which are mostly (but not exclusively) auto-generated from database tables by the Entity Framework. Additionally I use SVN (with TortoiseSVN) for version control.
So recently, after merging another branch, I noticed that some files went "missing". After checking them in the explorer, I noticed that they were renamed to entirely uppercase, e.g. FOO.CS, even though they were not renamed just modified in the branch I merged. Even stranger: When I tried to rename FOO.CS back to Foo.cs manually through the Windows Explorer, the file name instantly changed back to FOO.CS. Which files were renamed seemed random to me and I don't see anything that makes the renamed files different to any of the other files.
I am really clueless to what is happening here and this problem keeps re-emerging constantly in my Entity Framework project forcing me to manually copy changes to my branch (yuck!). At the moment I suspect SVN or TortoiseSVN to be the culprits here, but I might be wrong (maybe Visual Studio is messing with my file names, or it could be me doing something stupid?).
I couldn't find any threads about my problem, so any help would be much appreciated.
Well, turns out that Subversion wasn't the true culprit. The real problem was my local repository folder which was stored on a FAT32 drive. Apparently FAT32 does not distinguish between upper- and lowercase characters for file names and a newly created file named TEST.TXT shows the same behaviour as the FOO.CS I described in my question.
So using another file system like NTFS should solve my problem.
Related
I've been messing around with some public and work Git repos (all Github), as I grow my burgeoning C# expertise...
Especially for tutorial and course repos, they use a lot of folders. I also noticed you can add a "Solution Folder". However, I've also noticed Visual Studio has this love-hate relationship with folders, and sometimes they map to the physical folder, and sometimes they... just don't.
So - what can I use them for? Is there a good use case beyond just logically grouping files in a project to organize things a bit?
Oh! And one time I opened a folder from my drive directly in Visual Studio, and it showed up just like a solution - but it was just an open folder... it was kinda weird. What's up with that?
Links to Info
This Q&A (Actual folders in Visual Solution Explorer?) explains some more about how to keep folders in a solution mapped to the physical folders, which VS is very picky about and doesn't even try to keep in sync...
If I'm understanding your question correctly, there is essentially two most common uses for folders within your solution/project.
First and probably most obvious, folders are used to organize and group together relevant files. While this is more of a personal preference thing - I often use folders to organize my code similar to that of MVC (Model View Controller).
Second and usually less common but still something to be familiar with are folders that get copied into the output directory. These folders get created when you have a file with its advanced property Copy to Output Directory set to Copy always or Copy if newer. These files then become a part of the Build Action - upon building your solution, these files get copied to the output directory. This is used when there is a need for certain files within your solution such as a data file or external resource needed to interact with.
Example: I recently worked on a project that required my solution to interact with PhantomJs, which is an external standalone executable. I needed my code to make calls and pass data to this application - thus making it a vital part of my solution. PhantomJs was placed in a folder and set to Copy if newer which ensured my copy of the executable was an available resource during runtime.
Hei,
So we have a whole group of people working on the same project and every now and then some files show as hidden, you know the blank file icon like obj or bin.
See my font and texture? They should be normal.
So, I can see them in the folder but not in solution explorer without hitting the Show Hidden Files. I can also modify them but I would like them back.
I have been trying to see if there was a solution but all I get is blogs on how to show hidden files.
So I found this thread
Visual Studio 2012 and missing files
that seems to be giving the reason of my problem. People are not saving properly before pushing to github.
Now is there a solution to this?(apart from saving properly) Can I make all of those files become normal files?
Cheers
Simply right click the files/folders and include them to source control again.
This usually happens if people check in new files/folders but do NOT check in the updated project file, too. The project file contains a list of all files which should be included within the solution. If this runs out of sync, exactly this crap will happen... ;)
Simply instruct your folks to properly check-in. Or do code review on check-in and verify that the project/solution file(s) are also checked in.
They show up as hidden because they're not part of the project/solution, but they are on your file system.
You can right-click the files and click Include in Project
If this does not solve the issue after checking in. The project file is what is not properly getting checked in.
Probably the problem is that they are not pushing the project file (file with extension .csproj). It holds all references to files included on the project so it needs to be pushed when new files are added.
Let everyone know that they need to push this file in order to everyone to catch latest changes on project.
I'm writing a C# project which I want to compile both under VS2010 and VS2012. I want to have two different .csproj files for that, even though VS2010-project can be directly included in VS2012-solution. I want two different project files because of different target .NET-versions.
Additionally, I want both projects to be named the same within different solutions for VS2010 and VS2012. The both should share the same .cs-files and, possibly, some resources.
Easy task? Strange thing, but I don't know, how to do that properly.
First approach, doesn't work: name project files as MyProject10.csproj and MyProject12.csproj, leave both in the MyProject folder. But in this case they are displayed in solution as MyProject10 and MyProject12, not simply MyProject. If I rename one to MyProject in solution explorer, it automatically renames the corresponding project file.
Second approach, works, but has drawbacks. Move project files into different subdirectories, named VS10 and VS12, manually change include paths in .csproj-files, adding ..\ as a prefix. In this case I see strange shortcut-like arrows under the icons in solution explorer.
The only bad thing for the second approach is that when I add new files in the project using solution explorer, this file is placed in the VS10 subdirectory, not in the root project directory. But it seems like project directories for .csproj-files are the directories containing the file by design, and I use the dark side of the force which I really don't want to do.
Any better ideas?
Worth giving a try is changing the name of the output assembly in both projects to one and the same. The project files are still going to be different, but the output assembly will be with same name. Also be carefull where is the output directory. I think this way you can sovle your problem.
I am currently experimenting with TFS, and I really like it.
One small question, regarding test files:
I have a directory with some demo TXT, images, dirs... These are used during tests, so up until now, the path was hardcoded to a folder on my computer. Now I need to change this, of course, the TFS need access to the files too.
My idea was to place them inside the folder of my solution, I currently have roughly this structure:
Solution Folder
mysol.sln
SomeProjectDir
OtherProjectDir
_LIB for external .dll
_DEMO_FILES for test files
The whole solution folder is under source control. Would you do it the same way? How is the best and elegant way to get the "real" path of the folder for usage in unit tests? Using the execution path an cutting away the rest? Do test files belong under source control?
Thanks for any input,
Chris
EDIT: Beside the tip given in the answer, please be aware that with testing there are some pitfalls with this. The test is executed in a different folder (often named after some timecode), the testfiles do not get copied there automatically. Even if they are set to copy always.
The solution is to either add the files manually by using a attribute called DeploymentItem in the unit-test, or, in my opinion much better, adjust the Local.testsettings and add the folder there. Keep in mind, the folder itself will not be added, so you need to do it one level higher..
You will understand what I mean if you try it. Or search for DeploymentItem on google
test files are part of your project, so there is NO reason to keep them out of the version control system. You should commit to the version control system everything that is needed to build, test and run your system, including 3rd party libraries, config files, test files, and even arguably documentation. Please note that most of these things should be part of your Visual Studio solution as well.
In my projects usually I try to have all my resources as Embedded Resource, so that I don't need to figure out the path, they are compiled into the assembly. If for some reasons I can't go this way, I would make the build copy them to the output folder (so mark them as copy always in VS) and then use relative paths.
Good day all,
I have written an application that i require to have a certain directory structure/. Nothing complex but it will need an "Images" Folder which contains two other folders "Temp" and "Complete".
These folders are in my solution however upon publishing all the folders are gone and i can not find any way in which to cause these certain folders to persist.
Will i have to write some code that checks if these exist and create them or can i make an application directory structure exist from the very beginning.
Dont know if this is relevant but i am using WPF and deploying through click-once.
Thanks,
Kohan
Regardless of whether you find a solution to the installation part of your question it would be prudent to check that the folders exist either on application start up or when you need to access them. After all, someone could come along and delete them without realising that they're needed. You might want to report or log this as an error, but recreate them anyway.
I assume you are using Visual Studio to create your ClickOnce deployments. If so, you can get around this issue by using MageUI instead.
Create your desired folder structure separate from you project's source code and bin folders. Copy in all the files you want deployed. Use MageUI and when you create the application manifest, point it to the root folder you created. It will take care of all the subfolders.
Also, I wouldn't worry too much about what ChrisF said. ClickOnce files are deployed to a very obfuscated location that users should never be in. And if they are in there deleting stuff, you'll likely have much bigger problems that a missing subfolder.