How would a programmer migrate an old C# project to reasonably modern Microsoft VS 2019?
It seems I must explore moving files to sub directories to get more modern features in the IDE, in particular [Git] compatibility.
The source code compiles and executes. The original source code is from [many] years ago.
Preliminary Solution ... At least for git
I am not claiming this is useful. I have only used git for one check in and one diff so far.
A new project was created for Windows Forms (WF).. Since WF was the style of the old project. Then the whole older project was copied to the newly created project/solution folder. That seemed to be a requirement again for git as provided by MS VS2019. Git directories for both projects were deleted since there was [no] history. Uninformed Delete. Version control was disconnected and reconnected with warnings by IDE. Old project added to new solution via context menu. Eventually after some undesired behavior a check in and diff was performed. A single diff (compare to unmodified). Compare to unmodified is not being offered . Commit is possible. I have my doubts and suspicions. More testing required.
Should I create a new similar project and try to put the old files in the new project? The tags indicate CSharp. Any smarter approaches?
Is it easy or difficult to move the location of source files within the project?
C# project display shows files such as
FormXX and FormXX.Designer.cs and FormXX.resx
style. I assume I must preserve those relationships.
So I would like to keep the original source as much as possible. Yet there is a Git incompatability problem asked in another question.
The source files are at the same level as the solution files. Messages from the IDE lead me to believe that this may not be the modern style.
Related
I have a C# application, a VS2017 solution with 7 projects.
Is it possible to lock a *.cs file or a project in order to avoid me to do undesired modification?
Your best bet is source control. Using systems like TFS, Git, or Subversion, you can track changes, see who has changed what, roll back to previous states, and in some cases, mark files as read-only. Without source control, marking a file in the file system as read-only is your only real option.
A server is not required for source control. While some solutions do require one, Git and SVN can be entirely local.
I cloned an existing but almost empty project on my local machine through GitHub for Windows. Then I opened it in VS 2017 and added a few classes after what they all became marked up as "ignored" with red icons with "minus" sign on them.
When I tried to make a commit, (I want to make commits and push through GitHub App), non of the files where pushed.
Then I tried right-clicking on the files and adding them to source control. Then "minus" signs became "+".
I also thought maybe the problem lies in the fact that I didn't stage them. So I did (in VS). But I still cannot push these files. After an attempt to make a commit in GitHub app all my .cs files again become marked up with "minus" sign.
What is the reason of it and how to make them not be signed as "ignored"?
They are (most likely) being ignored by .gitignore file.
If you can't see anything obvious (check substrings of the file name as well as extension), then look for these and remove them:
/*
!/content/
Not sure if this helps the #Tanya, and here's my partially similar experience.
And sadly (as a reflection on my powers of observation) it turned out to be exactly as #goamn had suggested.
I was building a new console app (very short list of files) to help me do a backup activity, and I had called the VS project “backup”.
What I missed (at first and second glance) was that in the .gitignore was the line (in the “Backup & report files” of all likely places!):
# Backup & report files from converting an old project file
# to a newer Visual Studio version. Backup files are not needed,
# because we have git ;-)
Backup*
Merely removing this line from that file, even after I had (what appeared to me to be a horked) repository already set up and non functional in github, fixed it right up. I was able to commit the files with no problem.
Hope that helps.
Say the .gitignore file has this:
*.log
in it.
Now, a project that's named with a .Log suffix will not be committed(for example a project called CompanyName.Domain.Service.SubService.Log)
To add such a project to source control, you'd need to manually add it using:
git add <RootFolder>/<CompanyName.Domain.Service.SubService>.Log/* -f
This will force commit the change contrary to the opinion of the .gitignore file. However, this does not remove the .log from the .gitignore file. But once the force commit happens, the project is already in source control and will therefore not be subject to the .gitignore file. Thereafter, commits to this project will be committed.
You need to add first, ensure they're staged, commit, then push
We'd like to use SonarQube/SonarLint on a rather huge C# solution with around 40 projects (C++ solutions hopefully to come later on). However, we are struggling with VS integration. The issue is as follows:
We've defined a Quality Profile on the SonarQube server and bound our solution to that profile. As a result, SonarLint receives the profile as a .ruleset solution file, and creates a bunch of files:
The binding configuration (.sqconfig) (folder <solution dir>/SonarQube)
The solution ruleset (folder <solution dir>/SonarQube)
The project ruleset files (one for each project folder) which allow to adjust the solution ruleset on project level (great and (for us) important feature)
Now, we'd like to share our binding and rulesets accross our development team. Thus, we have checked in all the above files. However, this has a significant disadvantage: Each time SonarLint receives changes of the Quality Profile from the SonarQube server, we have a bunch of outgoing changes. Investigating those changes implies that most (if not all) files have not changed at all, but seem to only have been touched. This is a showstopper for us, since we do not want to deal with a "polluted" list of outgoing changes on a regular base.
Note that this can be reproduced rather easily:
Bind solution to quality profile
Check-in all new and changed files
Right-click on SonarQube connection, select Update
=> All ruleset files created by binding the solution are marked as outgoing changes (and none contains any actual changes), refreshing the Team Explorer view doesn't help
Therefore, we thought that we could exclude all SonarLint created files from TFS. This (to my understanding) should be fine for the solution ruleset (since that ruleset is synchronized with the SonarQube server automatically), and we could live with having each developer take care of the solution binding once for himself/herself. However, since it appears to not be possible to adjust Quality Profiles on the SonarQube server with respect to VS projects, we would loose the ability to use VS project specific rulesets (or would have to copy them around manually).
Thus, my question is: What are best practices for sharing SonarQube rulesets accross development teams when using SonarLint and TFS as version control system?
I am working on documenting a winForms project that isn't completely done being written, meaning there is another programmer who write the code right now. So I've already wrote some importent comments in a copy of the project.
In addition I use sandcastle to bulid the help file.
My question: what is the best way (if there is one) to copy the comments from the old copy of the project to the new version of it?
Maybe sandcastle can do something like import a documentation to a project?
I know it wasn't so smart to do so, still I have to check if there is a way to save the documentation work.
Visual Studio has a built in file difference function you can use to see where the two files are different. It should be then a matter of copy and paste of the changes you have made over to the "gold" copy of the file your other programmer has changed.
This link shows how to Compare two files in Visual Studio 2012
"You can invoke devenv.exe /diff list1.txt list2.txt from the command prompt or, if a Visual Studio instance is already running, you can type Tools.DiffFiles in the Command window"
I am having issues with check in my code files because of some changes I have made to the project and solution. I have renamed project files, added different project files in the solution and added many files in the existing project.
Now I am getting an error while checking in the code.
The error details are:
Check In: Operation not performed Could not find file
'....Console.csproj.vspscc'.
How do I create a vspscc file if it does not get created on its own?
Any help would be great and thanks in advance.
This looks pretty stupid on my part. I restarted my Visual Studio and I could perform the check in because Visual Studio created the vspscc file when it opened the projects and solution.
Answering my own question as fast as possible so nobody else prints my own negligence before me.
And for anybody who needs an answer as how to create a vspscc file, restart the visual studio IDE
I have also seen this in another situation (VS2012) where a simple restart didn't do the trick.
I had a number of new projects which I had added to an existing solution but in the wrong place. Undoing and re-adding seemed to be fine until check-in, where it complained that the newly added projects and related .vspscc files could not be found. It was looking for them in the original location rather than where they are now.
Resolution was to go to the Source Control Explorer, which still had check-in items against these files in their original (but non-existing) locations, as well as the files in their correct locations. Selecting these errant references and "Undo pending Changes" for these files did resolve the issue.
I'd try using File/SourceControl/ChangeSourceControl dialog and unbind (if necessary) then rebind the project to TFS to recreate the .csproj.vspscc.
I removed projects and have same issue, so my solution was to re-create the same projects with same name, then remove them cleanly :-) I hope this helps
I had a similar problem, but in my case I Visual Studio/TFS couldn't fine the .csproj file. Anyway, with the help of a colleague I was able to determine that the issue was within TFS itself. TFS may have a different view of your source code than Visual Studio does. I had created the wrong type of project (I'll call it Proj1) and deleted it from within VS. Then created the correct project type, which I'll call Proj2. When I when to check it into TFS it complained about Prog1.csproj, which confused me because I couldn't see it within VS. What I learned was that you have to go into TFS's Source Control Explorer. From there you'll see how TFS sees things. Sure enough, there was Proj1.csproj (and some other related files to Proj1). What I had to do within Source Control Explorer was undo the pending check-in's of those files and folders which I didn't want to check in and no longer existed anyway. Then TFS was happy and I could perform the check-in.