Home
%3CLINGO-SUB%20id%3D%22lingo-sub-318084%22%20slang%3D%22en-US%22%3EUpdate%20your%20Windows%20desktop%20app%20to%20.NET%20Core%203.0.100-preview-009754%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-318084%22%20slang%3D%22en-US%22%3E%0A%20%26lt%3Bmeta%20http-equiv%3D%22Content-Type%22%20content%3D%22text%2Fhtml%3B%20charset%3DUTF-8%22%20%2F%26gt%3B%3CSTRONG%3EFirst%20published%20on%20MSDN%20on%20Nov%2016%2C%202018%20%3C%2FSTRONG%3E%20%3CBR%20%2F%3E%20%3CA%20href%3D%22https%3A%2F%2Fblogs.msdn.microsoft.com%2Fappconsult%2F2018%2F10%2F29%2Fmove-your-first-steps-with-net-core-3-0-for-desktop-development%2F%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3E%20Recently%20%3C%2FA%3E%20we%20have%20learned%20how%20we%20can%20use%20the%20daily%20builds%20of%20.NET%20Core%203.0%20to%20start%20experimenting%20with%20the%20upcoming%20support%20for%20WPF%20and%20Windows%20Forms.%20In%20the%20post%20we%20took%20%3CA%20href%3D%22https%3A%2F%2Fgithub.com%2FMicrosoft%2FWindows-AppConsult-Samples-DesktopBridge%2Ftree%2Fmaster%2FBlog-WpfNetCore%2FExpenseIt%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3E%20a%20WPF%20project%20%3C%2FA%3E%20%2C%20a%20sample%20LOB%20app%20which%20I%20often%20use%20for%20my%20articles%20and%20sessions%2C%20and%20we%20migrated%20it%20to%20use%20.NET%20Core%203.0%20instead%20of%20the%20traditional%20.NET%20Framework.%20%3CBR%20%2F%3E%20%3CBR%20%2F%3E%20However%2C%20as%20highlighted%20in%20the%20previous%20post%2C%20the%20current%20.NET%20Core%203.0%20support%20is%20highly%20experimental.%20The%20framework%20hasn't%20reached%20the%20public%20preview%20stage%20yet%20and%20we%20can%20play%20with%20it%20only%20using%20the%20daily%20build.%20As%20such%2C%20it%20isn't%20a%20big%20surprise%20that%20the%20newest%20version%20of%20.NET%20Core%203.0%2C%20specifically%20build%20%3CSTRONG%3E%203.0.100-preview-009754%20%3C%2FSTRONG%3E%20%2C%20has%20broken%20a%20few%20things%20%F0%9F%98%83%3CBR%20%2F%3E%20%3CBR%20%2F%3E%20If%20you%20would%20try%20to%20open%20the%20project%3CA%20href%3D%22https%3A%2F%2Fblogs.msdn.microsoft.com%2Fappconsult%2F2018%2F10%2F29%2Fmove-your-first-steps-with-net-core-3-0-for-desktop-development%2F%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3E%20we%20have%20created%20the%20last%20time%3C%2FA%3E%20%2C%20we%20won't%20be%20able%20to%20do%20it%20anymore%20due%20to%20an%20error%20returned%20by%20Visual%20Studio.%20Let's%20see%20in%20this%20post%20how%20to%20fix%20them.%20As%20first%20step%2C%20remember%20to%20download%20the%20latest%20.NET%20Core%203.0%20daily%20build%20%3CA%20href%3D%22https%3A%2F%2Fgithub.com%2Fdotnet%2Fcore-sdk%2Fblob%2Fmaster%2FREADME.md%23installers-and-binaries%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3E%20from%20GitHub%20%3C%2FA%3E%20.%20%3CBR%20%2F%3E%3CH3%20id%3D%22welcome-visual-studio-2017-159%22%20id%3D%22toc-hId-1509055778%22%20id%3D%22toc-hId-1535863932%22%3EWelcome%20Visual%20Studio%202017%2015.9%3C%2FH3%3E%3CBR%20%2F%3E%20In%20the%20meantime%20the%20Visual%20Studio%20team%20has%20released%20a%20newer%20version%20of%20the%20IDE%2C%2015.9%20(previously%20available%20in%20the%20Preview%20channel)%2C%20which%20includes%20an%20important%20change%20regarding%20.NET%20Core.%20By%20default%2C%20in%20fact%2C%20Visual%20Studio%20will%20now%20use%20only%20the%20latest%20stable%20version%20of%20.NET%20Core%2C%20even%20if%20you%20have%20a%20preview%20version%20installed%20on%20your%20machine.%20As%20such%2C%20after%20upgrading%20to%20Visual%20Studio%202017%2015.9%2C%20if%20you%20try%20to%20open%20the%20project%20we%20have%20created%20the%20last%20time%20you%20will%20get%20the%20error%20%3CSTRONG%3E%20Project%20file%20is%20incomplete.%20Expected%20imports%20are%20missing.%20%3C%2FSTRONG%3E%20%3A%20%3CBR%20%2F%3E%20%3CBR%20%2F%3E%20%3CIMG%20src%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fimage%2Fserverpage%2Fimage-id%2F67924iB32FA1CF44D50AA5%22%20%2F%3E%20%3CBR%20%2F%3E%20%3CBR%20%2F%3E%20To%20enable%20the%20usage%20of%20the%20preview%20version%20of%20.NET%20Core%203.0%20we%20have%20just%20installed%20you%20need%20to%20go%20to%20%3CSTRONG%3E%20Tools%20-%26gt%3B%20Options%20-%26gt%3B%20Projects%20and%20Solutions%20-%26gt%3B%20.NET%20Core%20%3C%2FSTRONG%3E%20.%20You%20will%20find%20an%20option%20called%20%3CSTRONG%3E%20Use%20previews%20of%20the%20.NET%20Core%20SDK%20%3C%2FSTRONG%3E%20%2C%20which%20you%20must%20turn%20on.%20%3CBR%20%2F%3E%20%3CBR%20%2F%3E%20%3CIMG%20src%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fimage%2Fserverpage%2Fimage-id%2F67925iAF5A037C4D02359B%22%20%2F%3E%20%3CBR%20%2F%3E%20%3CBR%20%2F%3E%20Now%20you%20can%20safely%20open%20the%20project%20we%20have%20built%20the%20last%20time.%20Well%2C%20more%20or%20less%2C%20since%20you'll%20get%20again%20the%20same%20error.%20The%20reason%20is%20that%20the%20definition%20of%20the%20project%20has%20changed%20with%20the%20last%20build.%20We%20can%20see%20that%20by%20opening%20a%20command%20prompt%20and%20creating%20a%20new%20project%20with%20the%20command%3A%20%3CBR%20%2F%3E%3CCODE%3E%0A%20%20%20dotnet%20new%20wpf%0A%20%20%20%3CBR%20%2F%3E%0A%20%20%3C%2FCODE%3E%0A%20%20%3CBR%20%2F%3E%0A%20%20If%20we%20open%20the%20.csproj%20file%20with%20a%20text%20editor%20and%20we%20match%20it%20with%20the%20one%20of%20our%20existing%20project%2C%20we'll%20notice%20some%20differences%3A%0A%20%20%3CBR%20%2F%3E%0A%20%20%3CCODE%3E%0A%20%20%20%3CPROJECT%20sdk%3D%22Microsoft.NET.Sdk.WindowsDesktop%22%3E%0A%20%20%20%3CBR%20%2F%3E%0A%20%20%20%3CBR%20%2F%3E%0A%20%20%20%3CPROPERTYGROUP%3E%0A%20%20%20%3CBR%20%2F%3E%0A%20%20%20%3COUTPUTTYPE%3EWinExe%3C%2FOUTPUTTYPE%3E%0A%20%20%20%3CBR%20%2F%3E%0A%20%20%20%3CTARGETFRAMEWORK%3Enetcoreapp3.0%3C%2FTARGETFRAMEWORK%3E%0A%20%20%20%3CBR%20%2F%3E%0A%20%20%20%3CUSEWPF%3Etrue%3C%2FUSEWPF%3E%0A%20%20%20%3CBR%20%2F%3E%0A%20%20%20%3C%2FPROPERTYGROUP%3E%0A%20%20%20%3CBR%20%2F%3E%0A%20%20%20%3CBR%20%2F%3E%0A%20%20%20%3C%2FPROJECT%3E%0A%20%20%20%3CBR%20%2F%3E%0A%20%20%3C%2FCODE%3E%0A%20%20%3CBR%20%2F%3E%0A%20%20The%20file%20is%20simpler%20than%20the%20previous%20one.%20Other%20than%20a%20few%20key%20changes%20(like%20the%20name%20of%20the%20SDK)%2C%20we%20can%20notice%20in%20fact%20that%20we%20don't%20have%20anymore%20an%20entry%20for%20each%20file%20which%20compose%20the%20project.%20Now%2C%20in%20fact%2C%20the%20project%20will%20automatically%20consider%20all%20the%20files%20which%20are%20included%20in%20the%20folder%20as%20part%20of%20the%20application.%0A%20%20%3CBR%20%2F%3E%0A%20%20%3CBR%20%2F%3E%0A%20%20Let's%20update%20the%20.csproj%20file%20of%20our%0A%20%20%3CA%20href%3D%22https%3A%2F%2Fgithub.com%2FMicrosoft%2FWindows-AppConsult-Samples-DesktopBridge%2Ftree%2Fmaster%2FBlog-WpfNetCore%2FExpenseItNetCore%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3E%0A%20%20%20previous%20project%0A%20%20%3C%2FA%3E%0A%20%20to%20include%20the%20new%20changes.%20This%20is%20the%20final%20result%3A%0A%20%20%3CBR%20%2F%3E%0A%20%20%3CCODE%3E%0A%20%20%20%3CPROJECT%20sdk%3D%22Microsoft.NET.Sdk.WindowsDesktop%22%3E%0A%20%20%20%3CBR%20%2F%3E%0A%20%20%20%3CBR%20%2F%3E%0A%20%20%20%3CPROPERTYGROUP%3E%0A%20%20%20%3CBR%20%2F%3E%0A%20%20%20%3COUTPUTTYPE%3EWinExe%3C%2FOUTPUTTYPE%3E%0A%20%20%20%3CBR%20%2F%3E%0A%20%20%20%3CTARGETFRAMEWORK%3Enetcoreapp3.0%3C%2FTARGETFRAMEWORK%3E%0A%20%20%20%3CBR%20%2F%3E%0A%20%20%20%3CUSEWPF%3Etrue%3C%2FUSEWPF%3E%0A%20%20%20%3CBR%20%2F%3E%0A%20%20%20%3C%2FPROPERTYGROUP%3E%0A%20%20%20%3CBR%20%2F%3E%0A%20%20%20%3CBR%20%2F%3E%0A%20%20%20%3CITEMGROUP%3E%0A%20%20%20%3CBR%20%2F%3E%0A%20%20%20%3CCONTENT%20include%3D%22Watermark.png%22%3E%0A%20%20%20%3CBR%20%2F%3E%0A%20%20%20%3CCOPYTOOUTPUTDIRECTORY%3EPreserveNewest%3C%2FCOPYTOOUTPUTDIRECTORY%3E%0A%20%20%20%3CBR%20%2F%3E%0A%20%20%20%3C%2FCONTENT%3E%0A%20%20%20%3CBR%20%2F%3E%0A%20%20%20%3C%2FITEMGROUP%3E%0A%20%20%20%3CBR%20%2F%3E%0A%20%20%20%3C%2FPROJECT%3E%0A%20%20%20%3CBR%20%2F%3E%0A%20%20%3C%2FCODE%3E%0A%20%20%3CBR%20%2F%3E%0A%20%20Here%20are%20the%20changes%20we've%20made%3A%0A%20%20%3CBR%20%2F%3E%0A%20%20%3CUL%3E%0A%20%20%20%3CBR%20%2F%3E%0A%20%20%20%3CLI%3E%0A%20%20%20%20We%20have%20changed%20the%0A%20%20%20%20%3CSTRONG%3E%0A%20%20%20%20%20Sdk%0A%20%20%20%20%3C%2FSTRONG%3E%0A%20%20%20%20name%20in%20the%0A%20%20%20%20%3CSTRONG%3E%0A%20%20%20%20%20Project%0A%20%20%20%20%3C%2FSTRONG%3E%0A%20%20%20%20entry%20from%0A%20%20%20%20%3CSTRONG%3E%0A%20%20%20%20%20Microsoft.NET.Sdk.Wpf%0A%20%20%20%20%3C%2FSTRONG%3E%0A%20%20%20%20to%0A%20%20%20%20%3CSTRONG%3E%0A%20%20%20%20%20Microsoft.NET.Sdk.WindowsDesktop%0A%20%20%20%20%3C%2FSTRONG%3E%0A%20%20%20%20.%20Now%2C%20in%20fact%2C%20the%20SDK%20is%20unique%20regardless%20of%20the%20platform's%20choice%20(WPF%20or%20Windows%20Forms).%0A%20%20%20%3C%2FLI%3E%0A%20%20%20%3CBR%20%2F%3E%0A%20%20%20%3CLI%3E%0A%20%20%20%20We%20have%20added%20the%0A%20%20%20%20%3CSTRONG%3E%0A%20%20%20%20%20UseWpf%0A%20%20%20%20%3C%2FSTRONG%3E%0A%20%20%20%20entry%20and%20we%20have%20set%20it%20to%0A%20%20%20%20%3CSTRONG%3E%0A%20%20%20%20%20true%0A%20%20%20%20%3C%2FSTRONG%3E%0A%20%20%20%20.%20This%20is%20the%20new%20approach%20to%20specify%20the%20application's%20platform%2C%20in%20this%20case%20WPF.%0A%20%20%20%3C%2FLI%3E%0A%20%20%20%3CBR%20%2F%3E%0A%20%20%20%3CLI%3E%0A%20%20%20%20We%20have%20removed%20all%20the%20previous%20entries%20inside%20the%0A%20%20%20%20%3CSTRONG%3E%0A%20%20%20%20%20ItemGroup%0A%20%20%20%20%3C%2FSTRONG%3E%0A%20%20%20%20section%2C%20like%0A%20%20%20%20%3CSTRONG%3E%0A%20%20%20%20%20ApplicationDefinition%0A%20%20%20%20%3C%2FSTRONG%3E%0A%20%20%20%20or%0A%20%20%20%20%3CSTRONG%3E%0A%20%20%20%20%20Page%0A%20%20%20%20%3C%2FSTRONG%3E%0A%20%20%20%20.%20The%20only%20exception%20is%20for%20the%0A%20%20%20%20%3CSTRONG%3E%0A%20%20%20%20%20Watermark.png%0A%20%20%20%20%3C%2FSTRONG%3E%0A%20%20%20%20file%2C%20since%20we%20need%20to%20customize%20the%20build%20action%20and%20to%20set%20it%20as%0A%20%20%20%20%3CSTRONG%3E%0A%20%20%20%20%20Content%0A%20%20%20%20%3C%2FSTRONG%3E%0A%20%20%20%20.%0A%20%20%20%3C%2FLI%3E%0A%20%20%20%3CBR%20%2F%3E%0A%20%20%3C%2FUL%3E%0A%20%20%3CBR%20%2F%3E%0A%20%20That's%20it.%20Now%20try%20to%20reload%20the%20project%20in%20Visual%20Studio%20and%20it%20should%20be%20opened%20without%20problems.%20The%20application%20should%20compile%20and%20run%20just%20fine%2C%20even%20if%20with%20the%20same%20limitations%20we%20have%20seen%0A%20%20%3CA%20href%3D%22https%3A%2F%2Fblogs.msdn.microsoft.com%2Fappconsult%2F2018%2F10%2F29%2Fmove-your-first-steps-with-net-core-3-0-for-desktop-development%2F%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3E%0A%20%20%20in%20the%20previous%20post%0A%20%20%3C%2FA%3E%0A%20%20(like%20some%20debugging%20issues).%0A%20%20%3CBR%20%2F%3E%0A%20%20%3CBR%20%2F%3E%0A%20%20The%20new%20build%20of%20.NET%20Core%203.0%20has%20brought%20also%20an%20improvement%20in%20the%20compilation%20chain.%20If%20you%20remember%2C%0A%20%20%3CA%20href%3D%22https%3A%2F%2Fblogs.msdn.microsoft.com%2Fappconsult%2F2018%2F10%2F29%2Fmove-your-first-steps-with-net-core-3-0-for-desktop-development%2F%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3E%0A%20%20%20in%20the%20previous%20post%0A%20%20%3C%2FA%3E%0A%20%20we%20were%20forced%20to%20build%20and%20run%20the%20project%20using%20MSBuild%20and%20Visual%20Studio.%20Trying%20to%20do%20the%20same%20using%20the%20.NET%20Core%20CLI%20was%20resulting%20in%20a%20compilation%20error.%0A%20%20%3CBR%20%2F%3E%0A%20%20%3CBR%20%2F%3E%0A%20%20Now%2C%20instead%2C%20we%20can%20compile%20and%20run%20our%20project%20also%20using%20the%20command%20line%20interface.%20Open%20a%20command%20prompt%20and%20move%20to%20the%20folder%20which%20contains%20your%20project%2C%20then%20execute%20the%20following%20command%3A%0A%20%20%3CBR%20%2F%3E%0A%20%20%3CCODE%3E%0A%20%20%20dotnet%20build%0A%20%20%20%3CBR%20%2F%3E%0A%20%20%3C%2FCODE%3E%0A%20%20%3CBR%20%2F%3E%0A%20%20Unlike%20the%20last%20time%2C%20the%20operation%20will%20complete%20successfully.%0A%20%20%3CBR%20%2F%3E%0A%20%20%3CBR%20%2F%3E%0A%20%20%3CIMG%20src%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fimage%2Fserverpage%2Fimage-id%2F67927i969433E3A657D408%22%20%2F%3E%0A%20%20%3CBR%20%2F%3E%0A%20%20%3CBR%20%2F%3E%0A%20%20And%20if%20you%20type%3A%0A%20%20%3CBR%20%2F%3E%0A%20%20%3CCODE%3E%0A%20%20%20dotnet%20run%0A%20%20%20%3CBR%20%2F%3E%0A%20%20%3C%2FCODE%3E%0A%20%20%3CBR%20%2F%3E%0A%20%20your%20WPF%20application%20will%20start%20just%20fine.%0A%20%20%3CBR%20%2F%3E%0A%20%20%3CH3%20id%3D%22wrapping-up%22%20id%3D%22toc-hId--1043101183%22%20id%3D%22toc-hId--1016293029%22%3E%0A%20%20%20Wrapping%20up%0A%20%20%3C%2FH3%3E%0A%20%20%3CBR%20%2F%3E%0A%20%20In%20this%20post%20we%20have%20seen%20how%20we%20can%20migrate%20our%20WPF%20.NET%20Core%203.0%20project%20to%20use%20the%20latest%20daily%20build%2C%20which%20introduced%20some%20breaking%20changes%20in%20the%20project's%20definition.%0A%20%20%3CBR%20%2F%3E%0A%20%20Remember%20that%20.NET%20Core%203.0%20is%20still%20experimental.%20Starting%20to%20migrate%20your%20WPF%20and%20Windows%20Forms%20applications%20can%20be%20a%20good%20exercise%20to%20plan%20the%20future%20of%20your%20desktop%20application%2C%20but%20it%20shouldn't%20be%20used%20to%20move%20applications%20used%20in%20production.%0A%20%20%3CBR%20%2F%3E%0A%20%20%3CBR%20%2F%3E%0A%20%20You%20can%20find%20the%20updated%20code%0A%20%20%3CA%20href%3D%22https%3A%2F%2Fgithub.com%2FMicrosoft%2FWindows-AppConsult-Samples-DesktopBridge%2Ftree%2Fmaster%2FBlog-WpfNetCore%2FExpenseItNetCore%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3E%0A%20%20%20on%20GitHub%0A%20%20%3C%2FA%3E%0A%20%20.%0A%20%20%3CBR%20%2F%3E%0A%20%20%3CBR%20%2F%3E%0A%20%20Happy%20coding!%0A%20%0A%3C%2FLINGO-BODY%3E%3CLINGO-TEASER%20id%3D%22lingo-teaser-318084%22%20slang%3D%22en-US%22%3EFirst%20published%20on%20MSDN%20on%20Nov%2016%2C%202018%20Recently%20we%20have%20learned%20how%20we%20can%20use%20the%20daily%20builds%20of%20.%3C%2FLINGO-TEASER%3E%3CLINGO-LABS%20id%3D%22lingo-labs-318084%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3Enet%20core%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3Ewindows%20forms%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EWPF%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E
Microsoft
First published on MSDN on Nov 16, 2018
Recently we have learned how we can use the daily builds of .NET Core 3.0 to start experimenting with the upcoming support for WPF and Windows Forms. In the post we took a WPF project , a sample LOB app which I often use for my articles and sessions, and we migrated it to use .NET Core 3.0 instead of the traditional .NET Framework.

However, as highlighted in the previous post, the current .NET Core 3.0 support is highly experimental. The framework hasn't reached the public preview stage yet and we can play with it only using the daily build. As such, it isn't a big surprise that the newest version of .NET Core 3.0, specifically build 3.0.100-preview-009754 , has broken a few things 😃

If you would try to open the project we have created the last time , we won't be able to do it anymore due to an error returned by Visual Studio. Let's see in this post how to fix them. As first step, remember to download the latest .NET Core 3.0 daily build from GitHub .

Welcome Visual Studio 2017 15.9


In the meantime the Visual Studio team has released a newer version of the IDE, 15.9 (previously available in the Preview channel), which includes an important change regarding .NET Core. By default, in fact, Visual Studio will now use only the latest stable version of .NET Core, even if you have a preview version installed on your machine. As such, after upgrading to Visual Studio 2017 15.9, if you try to open the project we have created the last time you will get the error Project file is incomplete. Expected imports are missing. :



To enable the usage of the preview version of .NET Core 3.0 we have just installed you need to go to Tools -> Options -> Projects and Solutions -> .NET Core . You will find an option called Use previews of the .NET Core SDK , which you must turn on.



Now you can safely open the project we have built the last time. Well, more or less, since you'll get again the same error. The reason is that the definition of the project has changed with the last build. We can see that by opening a command prompt and creating a new project with the command:
dotnet new wpf

If we open the .csproj file with a text editor and we match it with the one of our existing project, we'll notice some differences:
<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">

<PropertyGroup>
<OutputType>WinExe</OutputType>
<TargetFramework>netcoreapp3.0</TargetFramework>
<UseWPF>true</UseWPF>
</PropertyGroup>

</Project>

The file is simpler than the previous one. Other than a few key changes (like the name of the SDK), we can notice in fact that we don't have anymore an entry for each file which compose the project. Now, in fact, the project will automatically consider all the files which are included in the folder as part of the application.

Let's update the .csproj file of our previous project to include the new changes. This is the final result:
<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">

<PropertyGroup>
<OutputType>WinExe</OutputType>
<TargetFramework>netcoreapp3.0</TargetFramework>
<UseWpf>true</UseWpf>
</PropertyGroup>

<ItemGroup>
<Content Include="Watermark.png">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</Content>
</ItemGroup>
</Project>

Here are the changes we've made:

  • We have changed the Sdk name in the Project entry from Microsoft.NET.Sdk.Wpf to Microsoft.NET.Sdk.WindowsDesktop . Now, in fact, the SDK is unique regardless of the platform's choice (WPF or Windows Forms).

  • We have added the UseWpf entry and we have set it to true . This is the new approach to specify the application's platform, in this case WPF.

  • We have removed all the previous entries inside the ItemGroup section, like ApplicationDefinition or Page . The only exception is for the Watermark.png file, since we need to customize the build action and to set it as Content .


That's it. Now try to reload the project in Visual Studio and it should be opened without problems. The application should compile and run just fine, even if with the same limitations we have seen in the previous post (like some debugging issues).

The new build of .NET Core 3.0 has brought also an improvement in the compilation chain. If you remember, in the previous post we were forced to build and run the project using MSBuild and Visual Studio. Trying to do the same using the .NET Core CLI was resulting in a compilation error.

Now, instead, we can compile and run our project also using the command line interface. Open a command prompt and move to the folder which contains your project, then execute the following command:
dotnet build

Unlike the last time, the operation will complete successfully.



And if you type:
dotnet run

your WPF application will start just fine.

Wrapping up


In this post we have seen how we can migrate our WPF .NET Core 3.0 project to use the latest daily build, which introduced some breaking changes in the project's definition.
Remember that .NET Core 3.0 is still experimental. Starting to migrate your WPF and Windows Forms applications can be a good exercise to plan the future of your desktop application, but it shouldn't be used to move applications used in production.

You can find the updated code on GitHub .

Happy coding!