project-system
project-system copied to clipboard
StartupObject property is not erased after enabling `Application Framework` property
Visual Studio Version: Int Preview 16.8.0 Preview 4.0 [30514.8.main]
Summary: If you disable the Application Framework
and reenable it, the StartupObject
in the vbproj file is not removed. This is specifically in VB Winforms applications.
Steps to Reproduce:
-
Open the VBWinforms.sln found in https://github.com/dotnet/winforms/tree/master/src/System.Windows.Forms/tests/IntegrationTests/VisualBasicTemplate.
-
With the properties pages and project file side to side, disable the
Enable application framework
property.StartupObject
property should appear. -
Reenable the
Enable application framework
property.
Expected Behavior: StartupObject
property should be removed.
Actual Behavior: StartupObject
property is not removed.
User Impact: If the user disables and then re-enables the Enable application framework
property without any other change, the project is in a weird state and shows an error dialogue as shown.
cc: @KathleenDollard
If the user goes:
- Disable application framework.
- Enable application framework, which creates that
StartupObject
property with(None)
as its value. - Disable application framework.
The
StartupObject
property will still be there and will cause the build to fail.
After doing some investigation, this issue is in the new ProjectSystem https://github.com/dotnet/project-system/blob/main/src/Microsoft.VisualStudio.Editors/PropPages/ApplicationPropPageVBWinForms.vb#L1557
This is incorrectly handling the case when unchecked.
cc: @kvenkatrajan
@KlausLoeffelmann It seems that StartupObject should be stored in Application.myapp and not in the project file based on the last comment in https://github.com/dotnet/project-system/issues/6787
What should be the expected behavior when Enable/Disable My Application Framework ?
This is working correctly in .net framework property pages for VB
@ocallesp @melytc should this have been closed? The original repo was for an SDK-style project.
This is issue is yet to be addressed in the new Project Properties UI.
I'm confused because there is seemingly contradictory expected behavior in the issue and then in the first comment. Could you clarify expected behavior
I'm confused because there is seemingly contradictory expected behavior in the issue and then in the first comment. Could you clarify expected behavior
I think my intent was to bring visibility to the bad state it ends up in: it causes a dialog window to show up, plus the project fails to build. Plus, it ends in a bad state for both when it's enabled and disabled.
@KlausLoeffelmann, for the new experience, what do you recommend? Should we erase the value and property when the ApplicationFramework property changes from disabled/enabled and vice versa?
Enable application framework, which creates that StartupObject property with (None) as its value.
Why would we have (None) for the StartupProject to begin with, when we're enabling the App Framework? Shouldn't it be {ProjectName].My.MyApplication?
Why would we have (None) for the StartupProject to begin with, when we're enabling the App Framework?
We don't have it for the new experience, so we can move away from it. Is there any scenario where we would need that value?
I am confused.
The Application Framework is on by default. We have something in the <StartupObject> (VbWinFormsFramework.My.MyApplication maybe? But I'd say it doesn't really matter)
- We disable the AppFramework. - Could we put the Form from application.myapp as StartObject?
- We enable the AppFramework (We could put VbWinFormsFramework.My.MyApplication here, but probaby anything else would be find.)
- We disable the AppFramework - again, we could put the Form from application.myapp as StartObject.
Would that work? Would it make sense?
https://github.com/dotnet/project-system/pull/8419 addresses this and ensures we have the correct values set in the project file and myapp file as described in the last comment.