The place for the VB community to join our collective voice! See https://github.com/CommunityVB/Main for more info.
@paul1956 I'll take a look at MsgBox... I value "muscle memory". ;-) Speaking of muscle memory, one of the annoyances with the "core" WinForms experience is that the toolbar item to "view code" is gone. You now have to either right click on the item and choose to view code or edit the form... or use keyboard to do so. However, when using the keyboard... I had it open the winforms designer in the .NET Framework version when highlighting the source file in the "core" version. If I unload the .NET Framework version, it seems to work as expected. So still very rough around the edges. ;-)
@vbjay I ran an (unofficial) survey regarding the usage of MsgBox; as it turns out more than 2/3rds of the people that took the survey either use it as their primary and/or mixed. In other words, less than 1/3rd stated that they never use it in their WinForms development. So it being removed will potentially impact (good or bad) the majority of those who are developing in VB... that's a pretty big impact. We still haven't recovered from the last time things significantly changed in the spirit of "course correcting" existing VB behaviors back in 2001/2002. I'm not saying changes are bad, just that the problem isn't really all that simple (it's not binary).
@DualBrain Using MessageBox is a lot more complicated and does not give the exact same semantics, MsgBox is part of the VB language just like "End". The reason I have heard it is not included and from my experience, is there are/is missing API('s) needed to "fully" support it that don't layer well. My version would be a breaking change (not that I understand exactly what is broken) I think I has to do with Z-order between Forms and/or blocking execution and I think whatever it is doesn't effect my use.
I created #2501 against WinForms to ask that these changed to included in the Read Me for Core and VS
Winforms: https://docs.microsoft.com/en-us/dotnet/api/system.windows.forms.dialogresult?view=netframework-4.8 Of course that matters if I am writing winforms or not.
WPF: https://docs.microsoft.com/en-us/dotnet/api/system.windows.messageboxresult?view=netframework-4.8
I use the one needed in the ui framework I am using.
They made it so that all you have to remember MessageBox.Show in either ui framework.
I am working in dailies to get the application model working. If anyone has been working on that, or is interested, let me know.
My status, it requires some extra stuff in the project file, but when we got that straight, we found a bug on something missing in the runtime. That is in PR and should be in daily builds next week.
Has anyone seen Tests just stop running, and when you look in Output Window/Tests you see
No test matches the given testcase filter `FullyQualifiedName=XUnitTestProject1.XUnitTestProject1.UnitTest1.AdditionTest|FullyQualifiedName=XUnitTestProject1.XUnitTestProject1.UnitTest1.EqualsTest|FullyQualifiedName=XUnitTestProject1.XUnitTestProject1.UnitTest1.MultiplicationTest|FullyQualifiedName...` in C:\Users\PaulM\Source\Repos\VBUncheckedMath\XUnitTestProject1\bin\Debug\netcoreapp3.1\XUnitTestProject1.dll
Merge this app into VS as a Add-On instead of a standalone application. https://github.com/paul1956/Code-Coverage
I just wrote a TechNet article on dynamic ordering/sorting Entity Framework data, perhaps this might be helpful for new to vb.net and want to work with Entity Framework may find helpful
(Doesn't appear to be in 16.4.4... but is in 16.5.0 Preview 2.0.)
To introduce ourselves. Our apps are all in Visual Basic and for the Windows Store only. We've looked at C# so many times but each time it slows us down, is less readable, and we're sticking with VB.Net for all our projects; if that means waiting for .net core then we will and then start to upgrade our apps. We have so much experience in VB.Net (going back to the original BASIC on DOS) and we've built internal libraries with 10's of thousands of lines of code, so we'd never move away from Visual Basic.
There are many ways to use the Framework designer for simple things. Before using TryConvert change the font to new Core default font, adjust all the forms so you don’t immediately need it. Use the backup project file from framework to open the core project and edit forms, you can use that to add additional forms as well with Mads file nesting extension. I have been porting stuff for a while now and most things take an afternoon including updating to .Net editorConfig file rules which is available under Dotnet/samples on Github.
Using 16.5 preview 2 provides a VB code fix for Null checks but crashes a lot if Vb Forms are open in designer. I do all form changes in Framework and the close each form before opening in Preview 2.
@paul1956 All our apps are WPF (we used to do UWP but it was too slow and lacked functionality). Until Microsoft support WPF designer and full vb.net (we do use the my namespace, but not that much) we can't move over. Our apps are also, generally, disk intensive, so Core 3.0 won't improve things performance wise and we already work around a lot of the .Net performance bottlenecks for disk io. But we'll start the transition as soon as it's ready for production so we're on the latest framework :)
@DuckheadUK_twitter the disk performance and startup is where I got the biggest boost (but I never worked around any issues) when I moved to Core 3.1. I pulled My out of Winforms GitHub repo and just wrapped it with
#If Not netcoreapp5_0 ThenI am still waiting for road map so I will have some idea when it "is ready".
@DuckheadUK_twitter From a business point of view, I am in complete agreement. All of my (current) projects are still in .NET; however, I am experimenting with a new project idea where I'm building it in .NET Core (WinForms). After stubbing my toes repeatedly, I'm now working on this project in .NET with a mindful eye on moving it to .NET Core. Basically each step forward, I'm trying out the project on .NET Core - this project is something I want to do not something that is under any pressure to get completed as it currently isn't made public to my clients (at this time). It also allows me to experiment with what is currently working, what isn't and (to some degree) influences some of what I'm working on since I am keeping an eye on the future. @paul1956 much of work arounds you describe are the very reason why there is hesitation in the move forward... it needs to be more complete and, if changes are required, simpler. ;-) Until then, some of us who are OK with getting cut by being on the bleeding edge will have to continue pushing for things to, well, continue. :-D
@paul1956 I don't want this to get into a .net discussion (it is a vb forum after-all), but UWP disk access has memory leaks, indexer can not be relied on, and performance, even with partial storageFiles is unusable for large numbers of files (>400). .Net 4.x is excellent, but we had to put in a lot of work around multi-threading when performing tasks on lots of files. Take something simple like copying 1,000 files, our code can do it approx 20% faster than standard .Net with a list (and disk IO is the limiter)
As for the comment about discussions, I appreciate the fact that you are being considerate; however, please don't feel that anything has to be excluded in these discussions as long VB is at the core of the discussion. I've had the long opinion that, especially with regards to VB, the lines are pretty blurred regarding where the language, tooling, framework and api exists.
@DualBrain No, we use .net only wherever possible, but copying is done more intelligently, for example, at it's basic level, a queue of files based on size have two threads copying, one from the top, one from the bottom, this ensures the lost time waiting for IO close, seek, open, etc on small files doesn't prevent any copy, as the large file/s are always copying. There's more to it, but that's the basics.
@DualBrain We spent over a year trying to get UWP to do disk IO in any performant way and failed, even Microsoft conceded it couldn't be done and wouldn't fix it; fortunately they allowed Win32 in the store which got us around a VB problem with await and concurrent loops :) - i.e. you can't await in one - with Win32 the disk IO doesn't need to be awaited, so we run it in a tight parallel loop (restricting the threat count, if you can actually call them threads) and put it all on a background thread - works much better - super fast disk IO in the background.
On the topic of My... does anyone here any any idea what the "plan" is regarding the future? I do see that "My" is (very sparcely) in 3.1; however, the only thing there is My.InternalXmlHelper. I also see that it is entirely possible to extend My using the instructions located at https://docs.microsoft.com/en-us/dotnet/visual-basic/developing-apps/customizing-extending-my/extending-the-my-namespace. So my question really comes down to a) is My going to be part of 5.0 or b) do we, as a community, need to build our own implementation given that the base does appear to be there? Obviously I don't want to see anyone duplicate efforts... but if the later is necessary, I don't mind being involved in getting it done.
I raise this as I'm a bit concerned by the "notice" that is located at https://github.com/dotnet/runtime/tree/master/src/libraries/Microsoft.VisualBasic.Core. "We are not accepting feature contributions to Microsoft.VisualBasic.Core. The library is effectively archived. The library and supporting language features are mature and no longer evolving, and the risk of code change likely exceeds the benefit. We will consider changes that address significant bugs or regressions, or changes that are necessary to continue shipping the binaries. Other changes will be rejected." If My isn't part of Microsoft.VisualBasic.Core... then where would it be?
@DualBrain Microsoft have said they're bringing the full 'my' namespace to VB and .net Core - They just haven't given any timelines or if it will be .net core 3.1 or .net core 5 - I'm assuming we'll find out at ignite in May and it'll be the same time as the full WPF/WinForms VB.net new project templates become available.
@DualBrain @DuckheadUK_twitter If you go to DotNet/WinForms and just looks at Master you will see almost all the missing VB stuff. Last I checked SingleInstance was missing. There are changes in the VS UI for Core apps that removed most of the VB Assembly Information, but actually most just moved to Package (Title is missing from the UI and is now manually set in Project File). The Repo is dependent on Core 5 but I have not seen any code that depends on it. What the did is a different split between VisualBasicCore and WinForms for what I think is a very good reason. VisualBasic core is portable and should run anywhere which is very good. For now to access stuff in SplashScreen and About you need to change the code. In Core 5 there is a shim (AssemblyInfo.vb which is not regenerated with changes in Assembly Info) that translates new info from when it exists in core to where Framework expects it (except for Title).