New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
.dSym is not properly generated unless configuration is Release #5524
Comments
Hello @MihaMarkic, thank you for your feedback! I have tried to reproduce your issue using latest stable on VS4Mac and I have not seen the same error as you [1], I duplicated the Release configuration successfully without any manual edits and the dsym is correctly generated on both configurations. I would need the build logs and your version information to continue to assisting you. To get full build logs just set the log verbosity to diagnostic at the following locations:
On Visual Studio for Windows you also want to add Note: this is done automatically on Visual Studio for Mac when the log verbosity is set to diagnostic. The easiest way to get exact version information:
Then copy/paste the version information (you can use the "Copy Information" button). We look forward to hearing from you! [1]: |
@dalexsoto Hi. I should have emphasized that I'm using VS2017 15.9.6. Will provide further info. |
@dalexsoto I think I've isolated the problem. Seems like it's not tied to configuration name, but to this steps:
IOW A "Build solution" fails to generate dSYM if there is an existing build. Full build generates dSYM correctly. Can you reproduce it? VS2017 info Installed Version: Enterprise Visual C++ 2017 00369-60000-00001-AA592 Application Insights Tools for Visual Studio Package 8.14.11009.1 ASP.NET and Web Tools 2017 15.9.04012.0 ASP.NET Core Blazor Language Services 0.7.0-rtm-20181115.1 ASP.NET Core Razor Language Services 15.8.31590 ASP.NET Web Frameworks and Tools 2017 5.2.60913.0 Azure App Service Tools v3.0.0 15.9.03024.0 Azure Functions and Web Jobs Tools 15.9.02046.0 C# Tools 2.10.0-beta2-63501-03+b9fb1610c87cccc8ceb74a770dba261a58e39c4a CodeRush for Roslyn 18.2.6.0 CodeRush for Roslyn Tool Windows 18.2.6.0 Common Azure Tools 1.10 DevExpress Reporting Extension 1.0 DevExpress Reporting Tools Extension 1.0 DevExpress.DeploymentTool 1.0 DevExpress.Win.LayoutAssistant Extension 1.0 Extensibility Message Bus 1.1.49 (remotes/origin/d15-8@ee674f3) GitHub.VisualStudio 2.7.1.6591 JavaScript Language Service 2.0 JavaScript Project System 2.0 JavaScript UWP Project System 2.0 Microsoft Azure Tools 2.9 Microsoft Continuous Delivery Tools for Visual Studio 0.4 Microsoft JVM Debugger 1.0 Microsoft Library Manager 1.0 Microsoft MI-Based Debugger 1.0 Microsoft Visual C++ Wizards 1.0 Microsoft Visual Studio Tools for Containers 1.1 Microsoft Visual Studio VC Package 1.0 MLGen Package Extension 1.0 Mono Debugging for Visual Studio 4.13.12-pre (9bc9548) NCrunch NuGet Package Manager 4.6.0 ProjectServicesPackage Extension 1.0 ResourcePackage Extension 1.0 ResourcePackage Extension 1.0 Snapshot Debugging Extension 1.0 SQL Server Data Tools 15.1.61901.03220 TypeScript Tools 15.9.20918.2001 Visual Basic Tools 2.10.0-beta2-63501-03+b9fb1610c87cccc8ceb74a770dba261a58e39c4a Visual F# Tools 10.2 for F# 4.5 15.8.0.0. Commit Hash: 6e26c5bacc8c4201e962f5bdde0a177f82f88691. Visual Studio Code Debug Adapter Host Package 1.0 Visual Studio Tools for Containers 1.0 Visual Studio Tools for Universal Windows Apps 15.0.28307.208 VisualStudio.Mac 1.0 WiX Toolset Visual Studio Extension 0.9.21.62588 Xamarin 4.12.3.79 (d15-9@260fa6a34) Xamarin Designer 4.16.13 (45a16efd4) Xamarin Templates 1.1.128 (6f5ebb2) Xamarin.Android SDK 9.1.5.0 (HEAD/4b951a3e7) Xamarin.iOS and Xamarin.Mac SDK 12.2.1.12 (65ec520) |
I'm also not entirely sure what triggers wrong build at 4. |
No, I am not seeing this from Visual Studio for Mac, I will let someone from the Visual Studio on Windows chime in to see if this is a Windows only issue. /cc @emaf |
Hey, we were able to reproduce this issue on Visual Studio and we're working to fix it. Thanks for reporting this problem @MihaMarkic! |
Awesome guys. |
Was this ever fixed? |
Yes, this was fixed (in PR #5576). |
I am still seeing this same problem in VS (Windows) 2019 v16.7.0 No matter what configuration or what cleaning i do, the dSYM folder never contains symbol information |
I'm seeing a dangerous behavior regarding .dSym files generation. I'm seeing that when not using Release configuration for building .ipa, a .dSym file is still generated, but it is pretty much empty - like 9KB instead of 45MB in my case. This isn't obvious to the user and not good when a symbolication is required.
The fact that this is linked to configuration name is a bad idea in first place.
Please consider adding a checkbox to project settings and a csproj node that controls generation of .dSym instead.
Workaround: pass "-dsym=true" to additional mtouch arguments.
Steps to Reproduce
Expected Behavior
.dSym file is properly generated
Actual Behavior
.dSym is almost empty - 9KB in my case.
Environment
VS 15.9.6
The text was updated successfully, but these errors were encountered: