|
perhaps some clue as to what is really happening during this crash, can be found in your OS application event logs. I am sure it is not entirely Microsoft Visual Studio's fault.
|
|
|
|
|
Nope. For someone (as in moi) that was admittedly anti-web a few years ago, I pretty much write everything as a web app nowadays, even small utilities. Crazy.
Sander Rossel wrote: Thought I'd check out the new WinForms in .NET Core.
You're brave 
|
|
|
|
|
This is a serious question. If you make small utilities as web apps, doesn't that mean you have to have access to a web server? I do a lot of WinForms tools, and it seems that getting a web service installed on a customer's server is a hurdle I've never tried to jump for small things. I may be missing something important though.
|
|
|
|
|
You're right, although once you have access to a web server and deploy automatically using CI/CD, adding an extra service is not so difficult anymore.
If it's a small utility for your own purposes, I guess you could run it directly from Visual Studio (which is what I do with some stuff).
|
|
|
|
|
Rich Shealer wrote: If you make small utilities as web apps, doesn't that mean you have to have access to a web server?
Sorry for the delayed response.
Our company manages our own servers (well, AWS hosted) for the product line, including development servers, etc., so I primarily install these utilities on the development server domain which we have access to internally or through a VPN. Also I probably should have clarified that these are utilities we use in-house for monitoring and managing rather than utilities we expose to our customers. If it's a utility that needs to be exposed to our customer, it gets folded into the customer-facing product somewhere under configuration / maintenance.
And if it's a really one-off thing that simply makes my life easier, I just host it locally under IIS and put the code in a company repo somewhere so that others have access to it if they want.
|
|
|
|
|
I made a small program in it recently (same thought process as you, figured I'd check it out).
Aside from some weird issues with visual studio (buttons not being there, shortcuts not working (F5 for some reason doesn't work)) I haven't had any major issues or crashes.
But I haven't done anything as "advanced" as you with it though, although I have a "export to pdf" feature in mind, I haven't had the time to implement it.
For the moment it's mostly reading / writing to a json file and downloading a image from the web. (so nothing advanced)
I'm also using the free visual studio one for that program (the community one) so I just blamed the weird stuff on that, but ...
Tom
|
|
|
|
|
I still haven't made the jump to .NET Core, and I've been telling myself I won't do that until WinForms is there and ready and usable.
Your post tells me I made the right decision.
|
|
|
|
|
Sander Rossel wrote: I thought Microsoft released a stable version,
The MS teams that are throwing out preview this and preview that ... Web this and WebApp that, Maui this and Xamarin that ...
imho, none of the stuff is usable, or reliable. i think there's some kind of "publish or perish" culture-thing at play ... sacrifice of quality for flag-hoisting.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
Use the WinAPI and the old common controls.
It be fast and predictive.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Hi Eddie, for you and i, and, other WinForm "veterans:" i wonder if they are "common" because we have long ago learned their quirks, and work-arounds for their limits.
Speaking from my experience teaching bright, mature, students C# and WinForm UI skills, i observe there is a steep initial learning curve. Watching students wrestle with the DataGridView reminds me how i've forgotten how overwhelming its ginormous number pf properties were to me.
i find little consistency in how the classic controls evolved from their origins in COM into VB%, and then C# WinForms.
When WPF came along, i had high hopes for its controls, but, i just could not get into it.
On the upside (?) ... the deficit in native controls imho created a commercial opportunity for 3rd. parties to thrive. My favorite WinForms 3rd. party controls remain the ones from Lidor Systems, the IntegralUI Suite, which i purchased with source code: they are visually beautiful and performant ... of course, i can't compare them with the much more expensive suites from Telerik, and DevXpress, etc., that i have never tried
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
BillWoodruff wrote: Hi Eddie, for you and i, and, other WinForm "veterans:" i wonder if they are "common" because we have long ago learned their quirks, and work-arounds for their limits.
That's a veteran? No, the first common controls were designed to be recoginizable (recognizabilty), to implement features for impaired (accessability).
The common controls were a revolution; after that, you nog longer needed manuals, because you could guess what a control asks you, and you could clearly see where it was.
They ARE still superiour, because a team designed them, instead of sales. Everyone on the planet recognizes COMCTL32.DLL. It's free, and even people with bad eye sight can use it.
Why choose anything less evolved? And by "evolved" I mean those features been there before Win95. And you still looking for something "better", eh?
I worked with Telerik and DevXpress. Those surely not "common" controls.
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I spent a whooping 10 minute with WinForm on .NET 5...
It all seem to work fine....
That was just out of curiosity, using WPF.
As a side note, if by .NET Core you mean .NETCore 3.1 or less, that might be the reason why. It was not yet fully supported by then. Try again with .NET 5!
|
|
|
|
|
Super Lloyd wrote: As a side note, if by .NET Core you mean .NETCore 3.1 or less, that might be the reason why. It was not yet fully supported by then. Try again with .NET 5!
This may the reason!
I'm on .NET Core 3.1.
I thought WinForms Core was already LTS, which would mean .NET Core 3.1 as .NET 5 isn't LTS 
Doesn't matter anymore though, switched to .NET Framework as I needed a library that was incompatible with .NET Core 
|
|
|
|
|
Control binding isn't working in .Net 5 last I checked (recently). I'd recommend testing. Net 6 Nov 9th and avoid .Net 5 for winforms.
|
|
|
|
|
I jumped in on .Net 1.1 and in .Net 3.5 I would say the baby was born
As it is a small tool I would stay in WinForm, for major developments chose a different stack.
Rene
|
|
|
|
|
Yeah, mainly doing WinForms as I have no hosting, nor does this party have hosting or money for it.
So a good old desktop application it is, and WinForms is still the simplest IMHO 
|
|
|
|
|
I have a small utility for reading log files from Azure blob space, all works as expected. I had no particular problems but it's a single window very simple application.
|
|
|
|
|
I've used .Net to open and read from an excel file and also suffered some crashes until I made it work. The main problem was (AFAICT) that once you create an Excel instance, it becomes a sink for input events, and if any other thread in your application also eats Windows events, this can lead to conflicts.
I solved these problems by opening the sheet, reading whatever I needed into a data structure, and immediately closing it again. I. e. not just closing the excel file, but also the excel application instance! Put all that into a try ... catch block and you're golden.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
I'm using Spreadsheetlight for this, so I have none of those issues
|
|
|
|
|
In the team I work in, we always pull all the data out of files into memory and close the file out. We also avoid using an external app to pull the data, so in this case, we would use ACE or INTEROP to rip the data directly from the spreadsheet, close the file and then do whatever else it is we would need or want to do.
|
|
|
|
|
I have some programs I made in NET Framework. Some have 180,000+ lines of code, including "in-house" controls, PDF generator and "visor", intensive graphics and lots of forms and controls.
I compiled the DLLs having the in-house controls in NET 5.0 without changes. Then I linked them to my programs and compile everything. 2 or 3 errors in calls not supported yet by NET Core, that I must rewrite and after that, everything worked OK. No Visual Studio crashes, no problems, no hidden controls... I do not know what could be wrong with your program.
|
|
|
|
|
Not sure if you know about this, but our shop uses this assembly to read/write excel files.
it handles .xls and .xlsx
NuGet Gallery NPOI 2.5.4[^]
|
|
|
|
|
I would use .NET Framework instead. Besides the issues you mentioned, I discovered the hard way that .NET Core didn't even allow me to view the Tab Order function. Once I switched to Framework, I was better off. Your results may vary, but I'd say it's worth a shot.
|
|
|
|
|
I spent a week building out a fairly small Forms application in .NET core (in VB no less!).
While I was able to make it work, I decided after the first week to transition back to Framework for the following reasons:
1. Speed of design - I'm not sure why, but the GUI design is dog-slow for CORE - probably 4x faster in Framework.
2. Build was much slower
3. I could never get my.settings variables to work correctly (seemed to be a known issue)
4. An unreasonable number of IDE crashes or freezes
5. LOTS of little things that just didn't work as expected.
My suggestion is to stick with Framework for at least another year. Let people with lots of free time and patience deal with Microsoft bugs.
"Qulatiy is Job #1"
|
|
|
|
|
determined that was a lie
Who could imagine - commercial company will lie! 
I said before and I repeat - don't be stupid to jump on "new" .NET Core - it is not. It's clumsy try of indian dancers to repeat success of MS Java creators. Never happen again.
.NET (being just virtual machine) was created.... WINDOWS ONLY(!). Unbelievable stupidity. But too much time past and too much code is done. WinForms STILL the best solution for "graphics intensive" apps. WPF still slow, because of many technical issues and architecture.
I really cry Gates and Ballmer left the company - THEY was base of the solid work, THEY hire proper professionals. Now it's just bunch of monkeys after 1-week courses "C# for total idiots". Pity, but MS as a company is walking corpse.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
