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
Related
I'm having trouble understanding a behaviour of Nuget. I've created a basic package that deploys a single Test.cs file into an "HtmlHelpers" folder in a project. I'm following the "convention based working directory" method described on the Nuget site.
The issue I'm having is Resharper file analysis isn't enabled for this file (the file doesn't compile currently, I've left off a semicolon):
But, if I rename the file from "Test.cs" to "Test2.cs" then Resharper analyses the file correctly showing the syntax error:
Has anyone got any idea what's happening here? Is there a list somewhere of Nuget-supplied source files that are then excluded from Resharper analysis? The file properties are the same as for any other C# file, set to Build Action "Compile" etc.
EDIT1
To answer questions from Stephen below, this is Resharper 8, I'm not currently on 9. I've tried closing and re-opening the solution and excluding and re-including the file, neither of which help.
Interestingly, with analysis working correctly on the renamed "Test2.cs", if I then rename it back to "Test.cs" the analysis switches off again :S
EDIT2
Just to add some more info to this, if you Nuget-deploy C# files using the .pp extension, Resharper analysis works correctly on the resulting .cs files. Go figure.
ReSharper excludes source code that has been delivered as part of a NuGet package from analysis - it treats it as third party code that you did not write and do not want to maintain. E.g. it won't show any inspection results for files such as jquery.js or angular.js - you don't own these, don't intend to maintain them as part of your project, and any changes you do make are likely to get overridden the next time you update the project. So, inspections are disabled for these files, but the files are still indexed to allow navigation.
Just in case anyone else has this issue it only happens if Nuget delivers a .cs file. If you get Nuget to deliver a .cs.pp file, Resharper correctly analyses the resulting .cs file in your solution.
I was new to Nuget when I started this work and it turns out I needed to make them .cs.pp files anyway in order to use the correct project namespace when importing. So the problem has gone away.
I have a sln with > 50 projects, and recently, when I moved to VS2013, every time I press F5 for a build, it will rebuild all the projects, even though I have just performed a build. The diagnostics show, that each project is marked as not up to date with the following error:
Project <PROJECT NAME> is not up to date. Missing input file 'c:\users\USER\appdata\local\temp\2\.netframework,version=v4.0,profile=client.assemblyattributes.cs
I have read these threads:
In Visual Studio 2010 why is the .NETFramework,Version=v4.0.AssemblyAttributes.cpp file created, and can I disable this?
https://social.msdn.microsoft.com/Forums/vstudio/en-US/15d65667-ac47-4234-9285-32a2cb397e32/migration-from-vs2008-to-vs2010-and-netframeworkversionv40assemblyattributescpp?forum=vcgeneral
but the suggestion there is to add the following line to the proj file:
<Target Name="GenerateTargetFrameworkMonikerAttribute" />
I did and it did not work. Suppressing the warning as MS suggestion will also not work as the project will remain "not up to date".
I am using VS2013, C# and VB projects. With the very same project and VS2012, such error is not raised and the projects are up to date.
Any suggestions?
UPDATE
Perhaps it is worth mentioning that I do have a few build definitions in the solution, where all of the projects are building for AnyCPU except one: http://screencast.com/t/fuw9k4IubN
I had the same problem and solved it by upgrading the ToolsVersion attribute in *.csproj files:
ToolsVersion="4.0" replaced with ToolsVersion="16.0"
(I’m using Visual Studio 2019, which is v16.x internally).
<Target Name="GenerateTargetFrameworkMonikerAttribute" />
Well, not a good idea, that accomplishes the exact opposite of the problem you are trying to solve. It forces MSBuild to create the AssemblyAttributes.cs file, inevitably your project needs to be rebuilt since the file is new. The Q+A you found addresses a completely different issue, these were C++ programmers that were trying to come to grips with a new linker warning in VS2010. They hate warnings that appear from nowhere from files that are not part of their project. Well, don't we all. The marked answer on that SO question is quite evil btw, that other guy posted a much better answer :)
Missing input file 'c:\users\USER\appdata\local\temp\2\.netframework...
There's a signal in this message, note the presence of the \2 subdirectory in that path name. That is a Big Red Flag, it is not normal. This auto-generated .cs file normally lives inside the TEMP directory, not a subdirectory of that folder. Surely this has something to do with your real problem.
MSBuild doesn't do anything special and simply uses System.IO.Path.GetTempPath() to generate the folder name. That method isn't special either, it simply delegates the job to the GetTempPath() winapi function. The diagnostic therefore is that on this build machine, that OS function sometimes generates an odd-ball path, picking a subdirectory of the TEMP folder. And that it doesn't always generate the same one, thus causing your projects to getting rebuilt.
There is at least one good theory for this behavior, mentioned by commenter #Darran Rowe to this blog post:
No, this is Terminal Services at work. When you log in over remote desktop, Windows will set the temp directory for the logon session to %LOCALAPPDATA%\Temp\<session id>
Rings a bell?
Try deleting the hidden .vs directry which is in the same folder than the solution file.
This worked for me
Close visual studio and Deleted the .sou files from the projects
I was getting the same error and I solved it by removing the project from my solution and re-adding it. It is a pain because then you have to add the inter project references back in.
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:
I've read about this technique: Shared assembly info in VS projects - JJameson's blog
Basically it means to create a SharedAssemblyInfo.cs with versioning information about the assembly, and adding this file as Link to all projects of the solution, so the actual file resides only in 1 location on disk.
My question deals with 2 scenarios:
Existing solution that doesn't use this mechanism: Is there a way to easily add the ShareAssemblyInfo to all projects? (lets say i have a solution with 50 projects).
When creating a new project, by default a new AssemblyInfo.cs is created. However i'd like to link automatically to the SharedAssemblyInfo as well.
Is there any solution for this? what is the common practice?
It is possible to link to a shared assembly info file in VS 2010. Ashish Jain has a good blog post about it: Sharing assembly version across projects in a solution.
After creating the shared assembly info file at the solution level, his instructions for linking to it from a project are:
Right click on the project, in which you wish to add the Shared
assembly file, and select Add -> Existing Item...
Select the file “SharedAssemblyInfo.cs” from the solution folder.
Instead of Add, click on the the arrow next to Add and click “Add as
Link”
Drag down the added linked file alongside AssemblyInfo.cs in the
same folder.
Repeat steps 1 – 4 for all projects for which you wish to add shared
assembly file.
I've tried this and it works.
First point could be solved with simple text editor that could handle several files at once and find/replace. Just open all of your csproj in it and replace string <Compile Include="Properties\AssemblyInfo.cs" /> with
<Compile Include="..\SharedAssemblyInfo.cs">
<Link>Properties\SharedAssemblyInfo.cs</Link>
</Compile>
Alternatively you could write a utility like that:
var files = Directory.GetFiles(yourSolutionDir, "*.csproj", SearchOption.AllDirectories);
foreach (var f in files) {
string contents = File.ReadAllText(f);
string result = contents.Replace("<Compile Include=\"Properties\\AssemblyInfo.cs\" />", putSecondStringHere_ItIsJustTooLong); // :)
File.WriteAllText(f, contents);
}
As for the second question... You could take a look at Visual Studio custom project templates , but I'm not sure it worth the efforts. You should IMO write test that will check this instead. It will be much simpler and outcome is actually almost the same.
UPD: About writing tests for checking solution/project files against some custom rules. Basically, sln/csproj format is simple enough to be parseable without much efforts. So if you want to have SharedAssemblyInfo.cs linked into every project - just parse csproj's and check that. Then put that checker in your build server and run it on each build. We have such system working currently and it costs something about two days to write but saved us many more (we have there more sophisticated rules and multi-solution project, so it was worth the efforts).
I won't write about this checking in detail here right now (it is not that short), but I'm going to write blog post about it soon - most probably till the end of this week. So, if you're interested - just check my blog soon :)
UPD: Here it is.
I have created an application to increment the file version automatically.
Download Applicaiton
add the following line to pre-build event command line
C:\temp\IncrementFileVersion.exe $(SolutionDir)\Properties\AssemblyInfo.cs
Build the project
To keep it simple the app only throws messages if there is an error, to confirm it worked fine you will need to check the file version in 'Assembly Information'
Note : You will have to reload the solution in Visual studio for 'Assembly Information' button to populate the fields, however your output file will have the updated version.
For suggestions and requests please email me at telson_alva#yahoo.com
This does not work for solution that has both C# and F# projects. c# project cannot reference shared f# file and vice versa.
The only option in this case is to make a separate project and refer to it from other projects
It seems like this setting should be stored in the solution file so it's shared across all users and part of source code control. Since we don't check in the suo file, each user has to set this separately which seems strange.
It is absolutely necessary that everyone can define their StartUp Project themselves, as Jon has already said. But to have a dedicated default one would be great, and as I can tell, it is possible!
If you don’t have a .suo file in your solution directory, Visual Studio picks the first project in your .sln file as the default startup project.
Close your Visual Studio and open the .sln file in your favorite text editor. Starting in line 4, you see all your projects encapsulated in Project – EndProject lines.
Cut and paste the desired default startup project to the top position.
Delete your .suo file.
Open your solution in Visual Studio. Ta daa!
In most cases, it does make sense to have a default on this.
It would be much better to accommodate a default startup project and store this in the .sln file, but which can be overridden by a developer in their .suo file. If the startup setting isn’t found in the .suo file, the default startup project in the .sln would be used.
Actually, this has been suggested on Visual Studio’s UserVoice.
Why should it be a non-user-specific preference?
If I've got a solution with 10 files in, and one developer is primarily testing/using one of those tools, why should that affect what I start up?
I think MS made the right choice on this one. The project I want to start is far from necessarily the project that other developers want to start.
I wrote a little command line utility for Windows called slnStartupProject to set the Startup Project automatically:
slnStartupProject slnFilename projectName
I personally use it to set the startup project after generating the solution with cmake that always sets a dummy ALL_BUILD project as the first project in the solution.
The source is on GitHub. Forks and feedback are welcome.
If you are using GIT, you can commit the default SUO file and then mark it as unchanged using
git update-index --assume-unchanged YourSolution.suo
It works also if you want to have more than one project in your default start group. The only disadvantage that I know about is that this command must be run by everyone who don't want to commit the SUO file.