Open jcouv opened 6 years ago
Some additional data points: After getting this error in VS, I tried building from the command-line hoping to repro there and capture some logs. But the command-line build passed. However, when I went back to VS and tried building again, I got another set of errors (copied below). Building from VS again didn't produce no errors after that.
34>------ Build started: Project: BasicVisualStudio, Configuration: Debug Any CPU ------
34>D:\repos\roslyn\src\VisualStudio\VisualBasic\Impl\Options\AdvancedOptionPage.vb(12,20): error BC30311: Value of type 'AdvancedOptionPageControl' cannot be converted to 'AbstractOptionPageControl'.
34>D:\repos\roslyn\src\VisualStudio\VisualBasic\Impl\Options\AdvancedOptionPageControl.xaml.vb(18,24): error BC30057: Too many arguments to 'Public Overloads Sub New()'.
34>D:\repos\roslyn\src\VisualStudio\VisualBasic\Impl\Options\AdvancedOptionPageControl.xaml.vb(20,13): error BC30451: 'InitializeComponent' is not declared. It may be inaccessible due to its protection level.
34>D:\repos\roslyn\src\VisualStudio\VisualBasic\Impl\Options\AdvancedOptionPageControl.xaml.vb(22,13): error BC30451: 'BindToFullSolutionAnalysisOption' is not declared. It may be inaccessible due to its protection level.
34>D:\repos\roslyn\src\VisualStudio\VisualBasic\Impl\Options\AdvancedOptionPageControl.xaml.vb(22,46): error BC30451: 'Enable_full_solution_analysis' is not declared. It may be inaccessible due to its protection level.
34>D:\repos\roslyn\src\VisualStudio\VisualBasic\Impl\Options\AdvancedOptionPageControl.xaml.vb(23,13): error BC30451: 'BindToOption' is not declared. It may be inaccessible due to its protection level.
...
`
@jcouv Typically if I've seen this there was some build failure earlier on, and this was just downstream failures.
There was no other error listed in the output, and retrying works. So it could be that an early build step silently failed. If that's the case, then there are two problems: why was it silent, and why did that early step fail at all?
@jcouv Have you seen this again?
I think I did. But I'm not sure. I'll take the bug to confirm this still repros and ping you if it does.
Just go it again today:
22>CSC : error CS2001: Source file 'D:\repos\roslyn2\Binaries\Obj\EditorFeatures.Wpf\Debug\InlineRename\Dashboard\Dashboard.g.cs' could not be found.
22>Done building project "nruyfidv.tmp_proj" -- FAILED.
Build has been canceled.
I've run into this again today. I strongly suspect this happens when switching branch.
Just now I had switched from features/async-streams
(which I'd been building/debugging) to dev15.6.x
. After switching branch, I opened VS and tried to run a test. That first build failed.
Hopefully that helps narrow down a repro.
same here. after switching branch and rebasing to master this happened with dotnet build
on a test project. needed a clean build with build.cmd
@jcouv : I've been seeing this quite frequently off late. I have the solution open in VS and build from commandline when it shows up the most. Closing VS fixes it. This wasn't as frequent in pre-16.3 builds. Any other workarounds that we could apply to our repo itself?
Here's the message I see:
CSC : error CS2001: Source file '~\artifacts\obj\Microsoft.VisualStudio.TestWindow\Debug\net472\VsHost\Tools
Options.g.cs' could not be found. [~\src\TestWindow\Package\Microsoft.VisualStudio.TestWindow.csproj]
My team has been seeing this since porting our WPF app to .NET Core, I have found that using the "Play" button to build and run the app rarely if ever runs into this issue, but Rebuild Solution will often fail to generate the xaml .g.cs files.
Hi,
I started to see this in one of my Azure Pipeline builds for the specific .AssemblyAttributes
file but random projects:
CSC : error CS2001: Source file 'D:\a\1\s\src\..\bld\obj\AnyCPU_Release\WorkItems\.AssemblyAttributes' could not be found. [D:\a\1\s\src\WorkItems\WorkItems.csproj]
I observed that this started to happen after net5.0 got installed by default in windows-latest machines.
Do we have a solution for this?
Thank you!
@eddynaka Can you file a new issue in this repo for that one? I think we'll have to move it to another team so that would be best for tracking.
Hi, I am experiencing the exact same issue. Sometimes second build helps, sometimes not. Sometimes it requires me to rebuild and then build few more times. Sometimes the build fails with:
Error CS2001: Source file '...\obj\Debug\Views....ToolBar.g.cs' could not be found.
Then, after rebuild: Unable to delete file "obj\Debug....dll". The process cannot access the file ...\obj\Debug....dll' because it is being used by another process.
Or:
CSC(0,0): Error CS2012: Cannot open '...\obj\Debug...Module.dll' for writing -- 'The process cannot access the file '...\obj\Debug...Module.dll' because it is being used by another process.'
Additional info about the project:
Must say that this makes it impossible to work, any change in code that requires a build, ends up with 10 min build/rebuild/build rebuild sequence.
Also, there is no issue in the code, it compiles and runs properly (after few attempts of build/rebuild).
Thanks for your help.
Update, I tried to change the target to single framework (for both net48 and net5.0-windows separately) and it works fine.. Is there any problem with multitargeting wpf?
I've filed dotnet/wpf#4299 to track this further.
Same problem, single target framework 4.7.2. Only seems to happen on the first build on a fresh checkout from git. After the first build is done it's working fine. If I then delete all .vs, bin and obj folders it happens again.
Same problem in WPF user control library after moving to .NET 5. But only in debug mode for me.
I was able to overcome issue .razor.g.cs could not be found
by shortening path to MyComponent.razor
to make sure that complete path to MyComponent.razor.g.cs
is shorter than 255.
I have experienced this issue with `Source file c:......\very long path\obj\Debug\net5.0\RazorDeclaration\Pages\MyComponent.razor.g.cs could not be found' and complete path was 262 chars, so I just renamed component for example to 'Short.razor' and the error is gone.
I'm getting such errors occasionally, when building in VS. Re-building once or twice resolves the issue. I'm still trying to get a binary log of this.
Tagging @jasonmalinowski