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.
Related
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
So in VS, I create a project, right? Let's say I'm following a tutorial that has extra code that I don't need that only serves to show examples for looping, threads, etc. - then moves onto the real code. I take notes of everything so I usually save a copy of my source code with a different name as future notes. Now the only thing with projects in VS or any other C# compiler is that if you save the file AS "..." or make a new file, sometimes I find that the compiler will now compile the new code or the old code (it gets me so mixed up).
I get why it does this though, to link to other sourcefiles right? Well anyway, all I want to know is how do I compile a different C# file within my project folder? I don't want to create a new project, it just makes it harder for me to organize.
Assuming you want to include a lot of files into project bu only compile one you can just change "Build action" to "none" from "compile" for CS files you don't want to build.
I am using MapForce for the first time. I was able to successfully create an XML mapping. However, I am not sure how to run the generated code in Visual Studio, so that I can use it and see the output. I generated the code for the mapping in C# and did try to run the "Mapping" Project in VS.
Unfortunately, I am not able to due to few errors. There isn't a good documentation on the folders that are created in the project. If I can get a documentation link that I can refer to or if somebody can define why those folders are there and how can I use them/ how I should be running those projects.
Please correct me if I am wrong anywhere.
If you generated code to C:\MyFolder\, then you need to open in Visual Studio the solution C:\MyFolder\Mapping\Mapping.sln. Note that the "Mapping" is the default name, if you configured it to be something else from MapForce settings, then it may be different.
Solutions in other generated folders are supporting libraries, and you should never edit them (or at least do so at your own risk). The only file you can (but you don't normally need to) modify is called MappingConsole.cs. For example, you may want to change the paths of the mapping input/output files. In any case, after you build and run the solution, a Mapping.exe application is created in the Bin\Debug folder.
It would have been helpful if you indicated which errors you get. Perhaps the paths to the mapping input files cannot be resolved relative to the Mapping.exe application?
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 have the following problem.
I made an application in C# (using Visual Studio 2010). Everything worked fine.
Then I had to make some changes in a "main.cs". Did those... all fine again.
Then I had to make other changes in same file. Did those... cleaned the solution built it. The problem is that when I run/debug/anything the application I get the same result as I did before I made the changes. I even tried to break the code (called a random function that didn't exist, used wrong syntax), but the result was the same "Build successful" and the old version.
Is there some kind of cacheing mechanism or something? How do I get rid of this problem?
I added prints for the "compile" solution... I can't find the build property.
Try deleting the bin and obj directories in the Visual Studio project directory. The obj directory contains the temporary files used to create the binary while the bin directory contains the binaries for that project. In addition, check if there are any warnings being shown when you build your solution.
I was able to reproduce the same error i.e. build successfully even though the file has not been compiled. The Build Action of the file had not been set to Compile.
The correct Build Action for a code file (main.cs) would be Compile.
According the updated question the file properties does not have the compile option
The reason for this is that the file (main.cs) has not been included in the project, but the "Show all files" button is "on" in the Solution Explorer. The file has not been included in the project (hence not compiled) and the file icon is greyed out in Solution Explorer.
To include this file in the project, right click on add existing item to the project (see following image). In the subsequent dialog select the file (main.cs) and click on the add button.
This should solve your problem.
In future, it is best to keep the "Show All Files" button as "off" to avoid confusion.
Is it possible you have selected the build and run last successful version? Check out my answer to something similar here. If the changes you made broke something and you had checked the boxes and hit yes to the dialog boxes in my answer below then that's most likely the issue.
Cannot see changes I make when I run my application in Visual Studio
Make a backup of your solution.
Delete the .cs files from within the solution explorer. If your program compiles and runs, than you are linked to source folders and not actually using the one in your solution.
I doubt this is it, but worth a try. The other things that came to mind you have already eliminated out with the previous answers.