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.
Related
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.
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
I would like to Supress the Merge/Conflict checking for a few source files in a project on Get Latest Version. This is because these source files are autogenerated by a pre-build step. I just want them to be either left with 'local copy' or overwritten by the server version, because they're replace before building anyway and it doesn't matter.
When somebody on my team does a Get Latest Version, of course, these they get merge conflict errors, which isn't a big deal, but since the team changes from time to time, I get emails for a few weeks from new team members saying 'Am I going to lose my changes if I overwrite', until they finally remember to look at the filename.
Which of course caused a dev to get lazy once and ignore a merge warning, on a real source file ... and lose his changes!
Is there any way to tell TFS not to worry about this ... or, better yet, since the pre-build step always creates new versions of these files, just have them in the project (they're needed for building) but not in TFS?
You can always remove the binding of that file, so that it's not added to SourceControl.
Select the file in your solution.
In Visual Studio, File -> Source Control -> Exclude file from source control
The file will be part of your project but wont be under sourcecontrol. Basically it adds an entry to the ".vspscc" file to ignore the particular file.
Example from Vs2008 solution file.
Edit by O.P.
Note, as stated, this is not on the right-click of the file in project explorer!
Visual Studio 2012 has it hidden a bit better then vs 2008:
This question is NOT answered at the link above...
I had some problems with TFS where visual studio builds on the local machine no problem, but when I try to build on the server I get build errors. The errors are not relevant to this question.
The issue I have is that in order to fix the errors I had to manually edit some of the files on my local machine, and since they were manually edited, TFS doesn't detect the change so it wont let me upload my change set to the server which would have fixed the problems there.
My first, and main question is:
How can I force TFS to copy all my local files to the server. Sort of like the reverse of the whole:
Goto View / Other Windows / Source Control Explorer / Right click on the relevant project / Advanced / Get specific version / Check "Overwrite all files..." / Press ok.
Which (arguably, cause it doesn't always get everything in my experience) gets a full file set from the server to the local machine.
I am so tired of TFS uploading partial file sets and then when the solution is removed locally, and then re downloaded from the server, I have to pull in the missing files and references from some backup. If it was uploaded fully, and correctly at the start, I would probably have less of these problems. So this is my main question. How do I force TFS to upload all my files regardless if they have changed or not according to it.
To explain further a problem I am having in particular with nuget package manager. I disabled the option "Allow NuGet to download missing packages during build". So locally I got actual build errors. Yes that's right, Build errors. like this...
Project XXX: Package restore is disabled by default. To give consent,
open the Visual Studio Options dialog, click on Package Manager node
and check 'Allow NuGet to download missing packages during build.' You
can also give consent by setting the environment variable
'EnableNuGetPackageRestore' to 'true'.
Which now forces me to re-enable this option to get rid of the errors. I am annoyed at this because such errors should be presented as warnings so as not to prevent a build. This is seriously disappointing and as a result I have a very poor opinion of NuGet.
Anyways enough ranting, I re-enabled this, not like I had a choice. But the version where this was disabled went up to the server. Now I get this error on the server. I tried re-enabling it and doing a check in, but TFS wont let me. (Warning...No pending changes). Of course not, its just a silly check box. What could possibly have changed. But now I get an error on the server that I cannot fix all because someone at NuGet didn't put some taught into properly designing their warnings (as opposed to preventing a build by causing errors).
So, once again, how can I force TFS to take all my files, changed or unchanged, verbatim, to the server. This way, when I fix a problem locally, it "should" fix it also on the server. Or at least, when I next download it, I am assured to have the whole file set.
Apologies if this sounds like I am being negative, but I am at this for 5 solid days and it has completely stopped development costing me and the company a lot of money. Any help would be very much appreciated.
There is no way to tell TFS to take everything in my file system. What you need to do is a multistep process. First Check Out the entire directory, this will not overwrite your manual changes but will allow you to check back in and have it detect those changes. Second, if any new files were created you need to add at the root directory and get all new adds. Lastly check in all of your changes. It really should be that simple.
If you are using TFS 2012, then Local Workspaces would be a good solution for you.
Just to be clear - Local Workspaces does not mean that your developers are working locally. All code is still under Source Control in exactly the same way with Server Workspaces.
Local Workspaces are new to TFS 2012 and would resolve your issue. The main advantage for you is that files are no longer marked read-only. This allows you to be able to edit them from anywhere (notepad, any other IDE, Visual Studio) without first doing a checkout. Visual Studio will then automatically detect that the file has changed and list it in the Pending Changes window.
Good article comparing the different types of workspaces: http://blogs.msdn.com/b/willy-peter_schaub/archive/2011/11/30/team-foundation-server-trying-to-understand-server-versus-local-workspaces.aspx
I like to use the Source Control Explorer window, then right click on a folder and choose Compare. You can choose to see what is different in the target folder, or what is a new file. The files that are different appear in red. You can then right click on them and check out and check in files, or use control-click to select more than one file at time.
Yes i know before the flames start to arise, this is not conventional....but working in unity I encounter this problem quite often. Literally dealing with it now as i updated to unity 5.5 and it fubared a lot of stuff in my current project. After the resolutions from unity, my project is completely out of sync... and for whatever reason vis stu refuses to monitor these changes... It is rather annoying to be sure, but not to worry as I have resolved it successfully every time over the iterations by doing the following:
create a backup folder in a separate location and copy the entire thing over.
It doesn't matter where you back up to as long as its in a unique separate folder. Be sure to copy FOLDERS not individual FILES as some files may be hidden.
do a full get of the latest version (according to TFS).
This can take some time and is why you back it up in a separate location. Be sure to KEEP VS OPEN AT THIS POINT!!!
overwrite ALL the files you "got" with the backup that you made in step 1.
The local work-space will monitor the changes to the files as you overwrite them with the backed up copy into your local space, and mark them as having pending changes accordingly if the new one has any difference.
update your pending changes to the TFS server in source control explorer. Any change detected during the overwrite will be added to the included changes section.
Voila you have forced your files, work, and will onto the TFS server!
I've got licenses.licx file that is included to one of my projects properties. I am not sure how that is used by its dlls. Is it used by msbuild? Do you have any idea how it is used when the solution is building?
Since you indicate that StellarEleven's reply doesn't help, I guess you're looking for something even simpler. This is probably not 100% correct, but it is my understanding of how this works:
The licx file is simply a list of the "licensed" components used by your application.
Each line in the file is of the following format:
[Component Name], [Assembly Name]
For example one of my projects uses the licensed IP Works NetDial component so my .licx file contains the following line:
nsoftware.IPWorks.Netdial, nsoftware.IPWorks
In the context of the project (.csproj) file, the .licx file is referenced as an EmbeddedResource. During the build process, LC.exe verifies that the machine performing the build has the appropriate license(s) for the component in question, and generates a binary .licenses file which eventually gets embedded as a resource ([AssemblyName].exe.licenses) in the final executable.
Does this help?
Licenses.licx file woes
File this under ASP.NET, Department of WTF.
Frustration When you are developing a web application with our
controls, a mysterious file called licenses.licx appears. No, it's not
an order to use a weirdly-named lollipop, but is a transitional file
generated (and modified) by Visual Studio that participates in license
checking. In design mode, Visual Studio uses this file to make a note
of every licensed control you use in your design. When you then build
your application, Visual Studio read this licenses.licx file and for
every control mentioned there, will load the relevant assembly and run
the license code in that assembly to see if the assembly is properly
licensed (that is, that the product to which it belongs has been
properly installed on that machine). If everything checks out, Visual
Studio embeds the license key into the executable. If it doesn't,
you'll get weird error messages about the control not being licensed
(my favorite is "Could not transform licenses file 'licenses.licx'
into a binary resource." to which I usually invoke the colorful
language of my ancestors).
Licenses.licx is actually a file in your solution (if you cannot see
it there, click Show All Files). Visual Studio uses a program called
lc.exe to compile the licenses into embedded resources in your
application, and when things go wrong with the license compiling I've
seen error messages that reference this executable as well.
Here's an example of a line in a licenses.licx file.
DevExpress.XtraCharts.Web.WebChartControl,
DevExpress.XtraCharts.v8.2.Web, Version=8.2.4.0, Culture=neutral,
PublicKeyToken=9b171c9fd64da1d1
The first value in this comma delimited list is the class, the second
is the assembly where it's found, and the other values are the rest of
the assembly's strong name. I'm sure you can see problems already,
especially when you upgrade a solution to the latest versions of the
third-party controls you use. If you want, you can edit this file and
remove the strong name parts with no problem.
But that's not the biggest issue with licenses.licx. The thing is
Visual Studio has a propensity of touching this file if you open the
solution (that's "touching" as in changing the file date to the
current date/time). This plays havoc with licensing, especially if you
happen open the solution on a non-licensed machine and you are using
source control. Suddenly your build machine will throw off these
"cannot transform" messages and you're left wondering what went wrong.
Another prevalent issue is when you have a team of developers working
on a solution: they're all unconsciously "modifying" this file.
So, the answer seems to be not to put the licenses.licx file under
source control. (KB article)
But this solution to the problem throws another red flag: if one of
the developers in a team adds a new control that needs licensing to
the form, a line gets added to his local licenses.licx file and it may
not get reflected in source control. Bam, your build machine fails the
build and Joe, who added the control, has to buy doughnuts for the
team until someone else breaks the build.
I'm afraid I have no good solution to this latter issue, because
unfortunately the "not putting licenses.licx in source control" seems
to be the way everyone is solving the licensing problem. Another
solution is to delete the licenses.licx file altogether and then get
Visual Studio to regenerate it by opening the solution (although this
is a bit difficult on a build machine).
Anyway, hope that all helps in some way. And hitting your laptop with
a phone isn't really going to help.
We use a custom check-in policy (TFS) that explicitly nulls the contents of this while if present in the check-in list.