Open BennyBread opened 6 months ago
I have created a small sample app in this repo to reproduce the issue: WpfCsWin32PublishApp
I am NOT trying to publish an Appx Package, just a simple publish to folder..
@mslukewest is this an area you own as well?
Am seeing same issue across WPF and WAProj (Packaging Project) too. It's like the source generators aren't running at all.
Yes, that's what's happening IIRC. At least for wapproj packaging, it had some really weird way of building the referenced project that blocked source generators from running. So ultimately, this isn't a CsWin32 bug at all -- It's just that Cswin32 is the first source generator used by some of these users so it got the blame. :|
Re: aforementioned issue, interestingly, publish outside VS IDE (e.g., MSBuild with VS and dotnet SDK) work fine. Starting to wonder if it's a VS IDE bug?
Re: Waproj, yeah. It's old junk sadly.
@AArnott No, since this repro doesn't involve wapproj it's not something that's owned by my team. The build portion would be the dotnet sdk team.
However, I can tell you that the best way of investigating the root cause of an issue that repros when doing a publish in the IDE but not a 'dotnet publish'. I recommend installing this extension: https://marketplace.visualstudio.com/items?itemName=VisualStudioProductTeam.ProjectSystemTools2022, then turn on build logging and do the publish. You'll likely see that the 'publish' step is broken into a restore build and a publish build (based on what's in the publish profile), and you'll have a .binlog file for the failing publish.
Thanks to mention "dotnet publish". I just managed to publish my real project. Yay!! 🥇 💯
The sample project also publishes without problems using this command line:
dotnet publish WpfCsWin32PublishApp.sln -f net8.0-windows -r win-x64 -o .\publish -p:PublishSingleFile=true --no-self-contained -p:PublishReadyToRun=true
But it would of course be very desirable for most users if this would also work via VS IDE... ;-)
Removing AnyCPU
from <Platforms>
(or adding an explicit <Platforms>
with non-AnyCPU targets) from the repro project above seems to alleviate the issue. So it's some weird handling--waves hands--around there.
Here's a repro that includes wapproj. CsWin32WaprojDeployRepro.zip
The name 'Windows' does not exist in the current context [...]
X:\CsWin32DeployRepro\WpfApp\MainWindow.xaml.cs
@MSLukeWest Is this something you can help investigate? I tried filing a VS Community bug but the site is broken and isn't allowing new submissions.
@AArnott Would be great if you could help get some eyeballs on this. As it stands, no one can use the packaging project with CsWin32. I'm hard blocked on this 😢
Potentially dupe of https://github.com/microsoft/CsWin32/issues/560#issuecomment-2108707320
@riverar I already have started an email thread with a couple folks. Waiting on responses.
Here's a repro that includes wapproj. CsWin32WaprojDeployRepro.zip
@riverar your repro zip crashes 7-Zip and Windows Explorer when I open it. Any idea why?
Also, you say it includes "wapproj" but the zip itself is named for "waproj" (only one 'p'). It turns out from what I understand, both of those are real and distinct project types. Which one are you struggling with?
@riverar your repro zip crashes 7-Zip and Windows Explorer when I open it. Any idea why?
Probably the OS, here's a GitHub repo instead. https://github.com/riverar/3096bc50ded7
Also, you say it includes "wapproj" but the zip itself is named for "waproj" (only one 'p'). It turns out from what I understand, both of those are real and distinct project types. Which one are you struggling with?
Windows Application Packaging Project (wapproj).
I posted a workaround in https://github.com/microsoft/CsWin32/issues/560#issuecomment-2155486416 so if you want to keep this issue distinct for non-wapproj issues, happy to move the discussion there.
if you want to keep this issue distinct for non-wapproj issues, happy to move the discussion there.
Yes, please.
I'm getting the same error when trying to publisch my wpf application with this settings: net8.0-windows win-x64 framework dependend.
this is the logfile produced:
The minimal build output is more talkactive:
Seems the runtime generated Win32 pinvoke classes / files are not found.. ps: sorry for the big and long posting.
Originally posted by @BennyBread in https://github.com/microsoft/CsWin32/issues/560#issuecomment-2070310627