Build fixes #304
Build fixes #304
Conversation
Apparently, this project system was never taught to copy PDB and XML documentation files alongside the DLL they go with. We'll have to do it ourselves for now. For details, see: * dotnet/sdk#1458 * NuGet/Home#5926
|
|
|
Cool, very thoughtful. About the toast error, I moved from my own toast implementation to the "Microsoft.Toolkit.Uwp.Notifications" which seems to have an issue which I fixed myself in my code. I did have a quick check, but couldn't find it yet. I just upgraded the nuget locally, but don't know yet if this solves the issue... Honestly, I just added a try catch for now... |
|
Well, there wasn't anything wrong with the code as far as I could tell,
actually, I just had enabled a setting where any time COM code would return
an error code, the debugger would kick in, and it just so happened to land
there.
Re: not wanting to actually import the plugins into the main app, that
makes sense. Perhaps a separate project to pull in all the components and
build the installer would be a good idea, though? The XCOPY thing seems not
to "clean" properly. (There are files left behind after you run the clean
target for the solution -- note that I had to do this as `msbuild -t:clean
-restore` for some reason.)
…On Fri, Apr 2, 2021 at 5:45 PM Robin Krom ***@***.***> wrote:
Cool, very thoughtful.
But I cannot merge this.
It might look like your changes make sense, but I do not want to have
direct connection between Greenshot and the plugins.
Especially there should not be any leaking of dependencies, and this will
happend if you have a direct project reference.
It should be possible to install Greenshot without having any plugins.
About the toast error, I moved from my own toast implementation to the
"Microsoft.Toolkit.Uwp.Notifications" which seems to have an issue which I
fixed myself in my code. I did have a quick check, but couldn't find it
yet. I just upgraded the nuget locally, but don't know yet if this solves
the issue... Honestly, I just added a try catch for now...
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#304 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAADMT4UOXZUIQKOM373D3LTGY3IZANCNFSM42IGX5ZQ>
.
|
|
By the way, the reason I was trying to run in the debugger in the first place was that I was seeing something like Issue #116 (desktop was really eager to be clicked in "Capture Window" mode ...), but naturally it wasn't happening in my freshly launched build. |
Just a few build improvements I came up with due to debugger misconfiguration.
In particular, I had "Break when exceptions cross AppDomain or managed/native boundaries" enabled,
so the debugger broke in on a failed call somewhere inside WasCurrentProcessToastActivated(),
at which point I noticed that the debugger wasn't finding the symbols.
This turned out to be because the PDB files from NuGet dependencies weren't being propagated along with the DLLs.