I have a C# project with several different branches. I'm trying to separate out code for a specific feature into its own branch using git cherry-pick.
This involves cherry-picking about 20 or so commits from a Development branch into a separate Feature branch.
I'm kind of in the middle of this process (cherry picking in chronological order) and I'm trying to build the project in Visual Studio as I go along to check that everything is going OK.
However I'm getting some strange 'Source file .... could not be found' errors, for both .cs files and .xaml files.
Some of these errors refer to files I know will be added in future commits, so I'm not too worried about them. However others refer to files that were in the Development branch which I don't intend to bring to my Feature branch (as they are not part of the feature).
The strange thing is, while it's true that the offending files don't exist, I can't understand why Visual Studio is even looking for them - e.g. they hadn't been added to the project at the time of the commit, and indeed if I open the .csproj file there is no reference to them.
I've tried "Rebuild Solution" and even "Clean Solution" followed by "Rebuild".
Why would Visual Studio look for these files and then show an error that they don't exist? Is there some sort of build cache that I need to clear? (e.g. that may have been created the last time I built while on the Development branch?)
We have a scenario like this:
We have ~100 solutions containing 10 projects each.
Each solution copies its artefacts (i.e. its 10 dlls) to a shared single folder like C:\code/assemblies.
If I develop something for feature X, I'll open up SolutionX.
The source for all solutions/projects is local in a single Monorepo C:\code.
During debugging, when the method/class/whatever is implemented in project Y, it opens the corresponding file (which is nice). So there must be information available how to get to the source.
But when developing, I cannot navigate to the implementation e.g. by using F12 ("go to definition") but just get the signatures gathered from meta data. I'd like to have the same experience like during debugging.
So right now I open up a Visual Studio Code, open the folder containing the sources and do a "search in files".
Any better ideas?
N.b. Resharper is not an allowed option. Also doesn't play nice with Postsharp.
N.b. I don't know if it is important but all except one solution start an external program (the shell), since all except one solution contain only dlls.
I have done similar in Old project.
You can use Symbol with Visual Studio 2019. Simple steps can be:
A. Generate Symbols for projects :
In Solution Explorer, select the project.
Select the Properties icon (or press Alt+Enter).
In the side pane, choose Build.
In the Configuration list, choose Debug or Release.
Select the Advanced button.
In the Debugging information list, choose Full, Pdb-only, or Portable.
Refer for more information:
Set debug and release configurations in Visual Studio
Publish symbols for debugging
B. Use Symbol in Visual Studio:
In Visual Studio, open Tools > Options > Debugging > Symbols (or Debug > Options > Symbols).
Under Symbol file (.pdb) locations,
To use the Microsoft Symbol Servers or NuGet.org Symbol Server, select the checkbox.
To add a new symbol server location,
Select the + symbol in the toolbar.
Type the URL (http), network share, or local path of the symbol server or symbol location in the text field. Statement completion helps you find the correct format.
Tools - Options - Debugging - Symbols page
For more Details refer:
Configure symbol locations and loading options
I think you should analyze project dependencies (for example with https://www.ndepend.com/docs/visual-studio-dependency-graph ) and cluster your projects in less Solutions
Edit : I am editing this answer based on your comment. I think you are looking for two use cases
Peek into the source code of referenced binaries
Navigate to the source and then edit them in place
To achieve option (1)
In Visual Studio 2019, use the built in decompiler to help you with navigating to code outside of the solution. This is an experimental feature as of May 2020. By default this is disabled and you should enable it. Once enabled the F12 navigation will decompile and allow you to peek into the source code.
On the other side, the more you relax the compilation the better the decompilation. Meaning, you can turn off optimisations (if any). This doesn't have to do anything with symbol generation options.
If you are using visual studio 2017 (or) less, the same can be achieved by Telerik Just Decompile plugin (free). Check the feature View decompiled code in tabs
To Achieve option (2) :
You should reference source files rather than binaries, because you won't get the natural in-place edit with referencing binaries. There are always going to be caveats irrespective of the solution you choose. Referencing source can be done using the "Add as link" feature in Visual studio, where the source code belong to one solution and can be referenced as link (something like windows shortcuts) in all the other solutions. (https://andrewlock.net/including-linked-files-from-outside-the-project-directory-in-asp-net-core/). If you are referencing source, you need to remove the binary references.
And you also have to decide from an architectural standpoint on how this changes the way people develop and commit code. The point of referencing binaries is to make sure they are not edited for convenience, but that depends on the nature of the development team purely.
Conclusion
From a best practices standpoint, you either have to reference binaries and don't allow them to be edited (or) you allow source references and edit in place. But that depends purely on what you want to achieve.
I am running into a peculiar bug when developing on Visual Studio 2017 that I have been able to ignore for a while, but is now beginning to really bug me.
I refer to this issue as a bug rather than an error because I am still able to build my projects in Visual Studio and deploy them to my development device without errors or warnings from the build output. This might seem alright to ignore for a bit, but over time it has become an issue because my intellisense is underlining it in red as an error
every time I reference attributes from the Resource class. As you might guess, I refer this class a lot and the Visual Studio editor eventually becomes cluttered with these "errors" which (a) hinders my ability to find actual errors in my code and (b) irritates me beyond all reason...
"Error" Investigation
As shown in the last image, intellisense is picking up an "Ambiguous Reference" to each attribute in the Resource class. When I check my Resource.Designer.cs file I only see one reference, but get a second error
.
It is now telling me that that a "Member with the same name is already declared". This lead me to believe that there is a second Resource.Designer.cs file, but my solution explorer and windows explorer both show only one.
Attempted solutions
Changed the namespace from InventoryApp (the default namespace of the file) to InventoryApp.Resources. This rid me of the ghastly errors but, upon building the project, it reverts the namespace in the file back to it's default, and the errors pop back up. I was also told by somebody who knows better that this is a big no-no.
Deleted the Resource.Designer.cs file, deleted the "obj" and "bin" folders from the project, cleaned and rebuilt the solution, then added the new Resource.Designer.cs file back to my solution. This did nothing to solve the problem.
Created an entirely new project from scratch. Even after creating a Blank Android App from the Visual Studio templates, the error persists. This begs the question: Is this a problem with my installation of Xamarin.Android?
Side-notes
The Resource.Designer.cs file's Build Action is set to "Compile"
The .csproj config file contains the tags:
<AndroidResgenFile>Resources\Resource.Designer.cs</AndroidResgenFile>
<AndroidResgenClass>Resource</AndroidResgenClass>
<GenerateSerializationAssemblies>Off</GenerateSerializationAssemblies>
<AndroidUseLatestPlatformSdk>false</AndroidUseLatestPlatformSdk>
<TargetFrameworkVersion>v7.1</TargetFrameworkVersion>
<AndroidManifest>Properties\AndroidManifest.xml</AndroidManifest>
<MonoAndroidResourcePrefix>Resources</MonoAndroidResourcePrefix>
<MonoAndroidAssetsPrefix>Assets</MonoAndroidAssetsPrefix>
6/6/2018 Update
If you have ReSharper, you most likely will be able to disregard my per-project solution described below and, instead, simply install the latest version (currently ReSharper 2018.1.2). Apparently, the underlying issue was caused by a bug in a previous version. Upgrading resolved the issue for me.
See youtrack.jetbrains.com/issue/RSRP-469636 for more information.
Thanks to #davidbauduin over at Xamarin Forums for this information.
I believe I have figured out the underlying issue and have a viable solution.
Solution
Add the following to the <PropertyGroup> section in your .csproj file:
<AndroidUseManagedDesignTimeResourceGenerator>False</AndroidUseManagedDesignTimeResourceGenerator>
Reason
While previous versions of Visual Studio had that feature turned off by default, the latest VS2017 update (15.7.3) has it turned on. That feature generates a second Resources.Designer.cs file that results in the ambiguous reference issue.
You can verify by hovering over the resource constant with the Intellisense error, right-clicking, selecting "Go To Definition", and selecting the 1st item, which takes you to a Resource.Designer.cs file. If you repeat, but select the 2nd one, you'll be taken to a different Resource.Designer.cs file. One of these points to the obj\Debug\designtime\Resource.Designer.cs file. By setting that feature to False as described above, that Resource.Designer.cs file in the obj\Debug\designtime path will not be generated.
Information Regarding the AndroidUseManagedDesignTimeResourceGenerator Feature:
https://developer.xamarin.com/releases/android/xamarin.android_8/xamarin.android_8.1/#design-time-builds-managed-resource-parser
https://github.com/dotnet/project-system/blob/master/docs/design-time-builds.md#design-time-builds
Hope this helps!
I have a C#/WPF project built on Visual Studio 2013 Professional for work.
This project was originally built on a Windows 10 platform, but has been moved to another computer running Windows 7.
I have found that the project can be successfully built when the program first opens, and I have chosen "clean solution" first. After any change is made, an error appears (Note that I have removed the company name from the line):
"CSC : error CS1583: 'd:[Removed company+project name]\obj\Debug\CSCB4E1285F65D54791A82C162F265D41AD.TMP' is not a valid Win32 resource file".
I have searched for solutions and a common thing suggested is that there may be problems with an .ico files. I completely removed my icon file from the project and it did not resolve the error.
The Microsoft information on this error is:
"This error occurs when you specify a filename with the /win32res compiler option that is not a valid or correctly formatted Win32 resource file. In Visual Studio, the filename is specified in the Application pane of the Project Designer." I've looked in the Application pane and I could not find any /win32res options...
The building process itself is prone to hanging - Stopping at different points. I stop, clean solution, and rebuild which often gets a different result.
What could I do to better diagnose the error? Are there any tools that allow me to see where something went wrong?
Is there something that I have overlooked?
Any input would be great.
I have a WebApplication which contains reference to WCF services.
While building using Visual Studio 2010, Build fails without any error or warning. However building the .csproj using MsBuild is successful.
Can't figure out what should I try in Visual Studio, to resolve / diagnose the issue. Can you please help out?
I find out that the build has been failing,
From text displayed in status Bar.
From output window:
========== Build: 0 succeeded or up-to-date, 1 failed, 0 skipped ==========
The output tab includes configuration details.
------ Build started: Project: <projectName here> Configuration: Debug Any CPU
I noticed that if "Build + Intellisense" is selected in the Error List, it causes the error messages to be swallowed.
Change this option to "Build Only", and all error messages will be displayed:
I don't know if this is a bug in Visual Studio or what, but it certainly revealed hidden error messages that were the key to pinpointing the failure for me.
Some, like Richard J Foster, have suggested increasing the "MSBuild project build output verbosity" setting to "Diagnostic" (the highest possible option), but this didn't solve the problem for me, as Visual Studio appeared to be suppressing the error message(s) themselves.
As an alternative, you may try to use the raw output messages from the "Output" tab, which haven't been filtered by Visual Studio. Either do an in-place search for the strings "error" and/or "failed", or copy all of the output to your favorite text editor and do a search there.
To ensure that the Output window appears each time you do a build, you can go to Tools → Options → Projects and Solutions → General, and ensure that the option "Show Output Window when build starts" is checked.
As an additional troubleshooting step, it is also possible to build the project from the PowerShell command line by running dotnet build. This will show you the complete build output, including any errors that Visual Studio may be hiding.
I just ran into a similar situation. In my case, a custom action (from the MSBuildVersioning package available on Nuget.org - http://www.nuget.org/packages/MSBuildVersioning/) which appeared in the csproj file's BeforeBuild target was failing without triggering any error message in the normal place.
I was able to determine this by setting the "MSBuild project build output verbosity" (in the latest Visual Studio's Tools tab [Path: Tools > Options > Build and Run]) to "Diagnostic" as shown below. This then showed that the custom action (in my case HgVersionFile) was what had failed.
Here are some things that you can try:
If your solution contains more than one project, try building each project one at a time. (You may even want to try opening each project independently of the solution.)
If applicable, ensure that all of your projects (including dependencies and tests) target the same version of the .NET Framework. (Thanks to user764754 for this suggestion!)
Tip: Check Tools → Extension and Updates to ensure that your packages are up-to-date.
Ensure that all dependency projects are built to target the same platform as your main project.
Try restarting Visual Studio.
As suggested by Bill Yang, try running Visual Studio as Administrator, if you aren't already. (If you are already running Visual Studio as Administrator, perhaps try the opposite?)
Try restarting your computer.
Try "Rebuild All".
Run "Clean Solution", then remove your *vspscc* and *vssscc* files, restart Visual Studio, and then "Rebuild All".
As suggested by Andy, close Visual Studio, delete the .suo file, and restart Visual Studio.
As suggested by Arun Prasad E S, close Visual Studio, delete the .vs folder in your solution directory, and then re-open Visual Studio. (This folder is auto-generated by Visual Studio and contains cache, configuration settings, and more. More details can be found in these questions: Visual Studio - Deleting .vs folder and https://stackoverflow.com/q/48897191.)
As suggested by MrMalith, close Visual Studio, delete the obj folder in your solution directory, clear your temporary folder, and then re-open Visual Studio.
Delete the hidden .vs folder & restart Visual Studio. That worked for me.
I want to expand on Sasse's answer. I had to target the correct version of .NET to resolve the problem.
One project was giving me an error:
"The type or namespace name 'SomeNamespace' does not exist in the namespace 'BeforeSomeNamespace' (are you missing an assembly reference?)".
There was no error in the Error List window but the assembly had a yellow warning sign under "References".
I then saw that the referencing project targeted 4.5.1 and the referenced project 4.6.1. Changing 4.6.1 to 4.5.1 allowed the overall build to succeed.
Nothing was working for me so I deleted the .suo file, restarted VS, cleaned the projected, and then the build would work.
I tried many things like restarting Visual Studio, cleaning and rebuilding the solution, restarting the PC, etc., but none of them worked for me. I was finally able to solve the problem by doing the following:
First of all, make sure all the projects in your solution (including tests) are targeting the same .NET version. Then:
Save pending changes in the project and close Visual Studio
Find the exact location from file explorer and find "obj" file and open it,
Then, delete all the included files (some files won't remove, it doesn't matter, just skip them).
Use run command (by pressing Windows Key + R) and type "%temp%" and press enter to find temporary files.
Finally, delete them all.
On other possibility is that Visual Studio needs to run as Administrator, this might be related to deploying to local IIS server or other deployment need.
Just for the sake of completion and maybe helping someone encountering the same error again in the future, I was using Mahapps metro interface and changed the XAML of one window, but forgot to change the partial class in the code-behind. In that case, the build failed without an error or warning, and I was able to find it out by increasing the verbosity of the output from the settings:
In my case (VS 2019 v16.11.20), disabling Text Editor->C#->Advanced->Enable 'pull' diagnostics in the options solved the issue.
Double check for _underscore.aspx pages in your project.
I had a page and code-behind:
`myPage.aspx` and `myPage.aspx.vb`
when building the project, I'd get errors on the .aspx.vb page stating that properties defined on the .aspx page didn't exist, even though the page itself would build fine and there were NO OTHER ERRORS showing in the output (even with diagnostic level build output).
I then came across a page in the project that was named the same thing but with an underscore: _myPage.aspx - not sure where it came from, I deleted it, and the solution built fine.