.NET Megathread 3.5: await GetGoodPosts()

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > .NET Megathread 3.5: await GetGoodPosts()

«‹›300 »

Gul Banana: Nov 28, 2003

the one i mean is iirc ReflectPropertyDescriptor - the binding system sets up PropertyDecriptor things to watch changes, but the one used for POCOs gets kept in a global variable for some reason. it means that if you do something like expose a List in your vm, then bind to List.Count, the view never gets garbage collected.. and of course it's holding on to the viewmodel via .DataContext, so neither does that

# ? Jul 3, 2016 20:14

Adbot: ADBOT LOVES YOU

# ? Jun 10, 2024 20:21

Mister Duck: Oct 10, 2006; Fuck the goose

Gul Banana posted:

the one i mean is iirc ReflectPropertyDescriptor - the binding system sets up PropertyDecriptor things to watch changes, but the one used for POCOs gets kept in a global variable for some reason. it means that if you do something like expose a List in your vm, then bind to List.Count, the view never gets garbage collected.. and of course it's holding on to the viewmodel via .DataContext, so neither does that

I'll bring it up. If you can pop together a basic reproduction application for it as well that would be helpful. What you're saying sounds simple enough but it's always better if we have something you consider a definite reproduction so we can be 100% certain your specific case is fixed or handled via a workaround. If you file a connect and link me to it, you can upload there and I can bring it up in our bug triage on Tuesday. I can't guarantee it will be looked at and fixed but I can at least get a reason why not if it is rejected.

# ? Jul 4, 2016 05:07

Mr Shiny Pants: Nov 12, 2012

Could you guys maybe make some nice, classy default WPF controls for Windows?

It would go a long way to losing the "generic windows application" look and feel and give Windows a bit more consistency.

Make it easier to use touch and camera's?

Maybe integrate something like MVVM Cross or Light? All the boilerplate stuff like DataTemplate selectors?

# ? Jul 4, 2016 06:57

amotea: Mar 23, 2008; Grimey Drawer

Mister Duck posted:

What specific things do you want to see in WPF or what are your biggest pain points? There is certainly effort being put into WPF right now (some of it mine), but we only have so much we can do at once.

I'm surprised there are actually people working on WPF atm, nice.

The main problem is that WPF has some great concepts, but it hasn't evolved in years, we now live in a world of Rx, package managers, async/await etc.

This blog post from 2012 (!) states it pretty well: http://paulstovell.com/blog/six-years-of-wpf
WPF right now is like ASP stuff was 10 years ago, see how much that has changed and how much easier it has become to work with. WPF is still a big PITA to work with, but it's still the best tech for Windows .NET desktop programs.

Just look at this uservoice thing, it's the 4th most voted idea:
https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/6701990-make-wpf-open-source-and-accept-pull-requests-from

I think you can find the most important bugs on StackOverflow or Connect, I can't even remember them. The memory leaks come to mind, something about merged dictionaries not working correctly, dictionaries not sharing resources (everyone uses the custom SharedResourceDicitonary now), UI binding warnings when in fact there's nothing wrong, the calendar component sucks IIRC, etc.

Then there's the need for basic components to remove boiler plate stuff and promote best practices. Just as a simple example: I had to steal a ProgressRing UI component from the metro apps stuff .xaml (dunno what they call that tech stack right now). XAML could use some love also, simple expressions/mixing code in Bindings would be nice.

It's impossible to list all issues, most of the time when you need to implement something custom UI related you'll run into a weird problem and just use a workaround from StackOverflow and move on. The main point is: plugging holes won't do it.

BTW re: touch support, we disabled touch support entirely, thereby actually improving touch usability for our customers, so I'm interested to see what you come up with.

# ? Jul 4, 2016 11:18

Cryolite: Oct 2, 2006; sodium aluminum fluoride

Does something like Newtonsoft's Json.NET exist for XML that will allow me to deserialize XML into POCOs that do not have attributes like XmlElement, XmlAttribute, etc. from the namespace System.Xml.Serialization?

My company built a wrapper around a SOAP-with-REST-hacked-on API that can return responses that are either JSON or XML. We went down the route of using JSON since using Json.NET to handle the deserialization is easy, so we now have hundreds and hundreds of POCO types defined that represent all of the response types of this API. Throw in a few JsonConverters and boom you're done.

I found that when we accept XML in the response instead of JSON ("Accept" header of "text/xml"), the raw response time is up to 40% faster and the response sizes are smaller too due to how they structure their JSON. We think it's because they're doing weird things with serialization on their end, but that's another story.

Since XML is so much faster we'd like to switch to it. I wrote up a quick proof of concept that uses hand-written deserializers for each response using LINQ to XML and XPath in a custom MediaTypeFormatter just to show the speed improvement (my hand-written code is 20% faster at deserializing responses than Json.NET too!), but this involves writing this logic for every single response. That's potentially hundreds of what are essentially Func<Stream, Task<object>>s that we'd need to write and test.

Is there a way to take advantage of our custom POCOs so that we can re-use them all while deserializing from XML, with preferably good performance? Is there a library that could help with this?

Or am I better off implementing it from scratch? And if that's the best option, how do I approach this? Since I don't really know much about the best way to deserialize stuff, should I just look at Json.NET's source and copy it for XML?

# ? Jul 4, 2016 17:26

chippy: Aug 16, 2006; OK I DON'T GET IT

Cryolite posted:

Does something like Newtonsoft's Json.NET exist for XML that will allow me to deserialize XML into POCOs that do not have attributes like XmlElement, XmlAttribute, etc. from the namespace System.Xml.Serialization?

My company built a wrapper around a SOAP-with-REST-hacked-on API that can return responses that are either JSON or XML. We went down the route of using JSON since using Json.NET to handle the deserialization is easy, so we now have hundreds and hundreds of POCO types defined that represent all of the response types of this API. Throw in a few JsonConverters and boom you're done.

I found that when we accept XML in the response instead of JSON ("Accept" header of "text/xml"), the raw response time is up to 40% faster and the response sizes are smaller too due to how they structure their JSON. We think it's because they're doing weird things with serialization on their end, but that's another story.

Since XML is so much faster we'd like to switch to it. I wrote up a quick proof of concept that uses hand-written deserializers for each response using LINQ to XML and XPath in a custom MediaTypeFormatter just to show the speed improvement (my hand-written code is 20% faster at deserializing responses than Json.NET too!), but this involves writing this logic for every single response. That's potentially hundreds of what are essentially Func<Stream, Task<object>>s that we'd need to write and test.

Is there a way to take advantage of our custom POCOs so that we can re-use them all while deserializing from XML, with preferably good performance? Is there a library that could help with this?

Or am I better off implementing it from scratch? And if that's the best option, how do I approach this? Since I don't really know much about the best way to deserialize stuff, should I just look at Json.NET's source and copy it for XML?

XMLSerializer does it.

http://stackoverflow.com/questions/3356976/how-to-serialize-deserialize-simple-classes-to-xml-and-back

# ? Jul 4, 2016 17:30

Cryolite: Oct 2, 2006; sodium aluminum fluoride

I've tried XmlSerializer but had a lot of trouble getting it to work. Our class and property names use Pascal casing but the XML is all lowercase so as far as I know we'd need to put XmlAttribute and XmlElement attributes everywhere. We also use inheritance which means we'd have to put attributes on the base type indicating which types inherit from it. There's an overload of Deserialize that takes a collection of additional types for inheritance but we don't always know the types at that point. We also need to deserialize into polymorphic collections which XmlSerializer does not support without type information in the XML I think.

# ? Jul 4, 2016 20:51

raminasi: Jan 25, 2005; a last drink with no ice

I'm trying to teach myself Web API and don't know anything about anything. The setup is this: We've got access to a page that makes data available in human-readable format, and I'd like to make it easy for other software to get the data too, via an API. So the application I'm making needs to know the URI of the original source, but I don't want to hardcode it or even leave it in the repository at all. How do I provide it? I can't find the magic words to google.

# ? Jul 4, 2016 21:21

john donne: Apr 10, 2016; All suitors of all sorts themselves enthral;

So on his back lies this whale wantoning,

And in his gulf-like throat, sucks everything

That passeth near.

In what way is the URL of your API different than a connection string to a database? How do you provide that information to your application?

# ? Jul 5, 2016 01:47

AWWNAW: Dec 30, 2008

If you don't want it in source control you can provide it via environment variable, configuration server, pack it in during your build process, etc. You have many options. Unless it's going to change often or is "secret", why wouldn't you just provide it via .config?

# ? Jul 5, 2016 02:15

ModeSix: Mar 14, 2009

I'm just learning ASP.Net Core and I have a question or two.

Would I need to use something like AngularJS alongside the ASP.Net Core ecosystem, or is it possible to do everything in straight C# that Angular can do?

If C# covers everything Angular will do, when would it be desirable or useful to bring in a 3rd party framework such as Angular or React?

# ? Jul 5, 2016 03:17

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

ModeSix posted:

I'm just learning ASP.Net Core and I have a question or two.

Would I need to use something like AngularJS alongside the ASP.Net Core ecosystem, or is it possible to do everything in straight C# that Angular can do?

If C# covers everything Angular will do, when would it be desirable or useful to bring in a 3rd party framework such as Angular or React?

JavaScript runs in the browser. C# runs on the back-end. They are different tools.

# ? Jul 5, 2016 03:33

ModeSix: Mar 14, 2009

Ithaqua posted:

JavaScript runs in the browser. C# runs on the back-end. They are different tools.

So would it be more in-line to consider the C# portion in the same frame as PHP?

# ? Jul 5, 2016 03:40

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

ModeSix posted:

So would it be more in-line to consider the C# portion in the same frame as PHP?

That would be the more appropriate comparison, yes. The C# stuff all runs *before* the page is sent to the client.

# ? Jul 5, 2016 03:52

epswing: Nov 4, 2003; Soiled Meat

Mister Duck posted:

What specific things do you want to see in WPF or what are your biggest pain points? There is certainly effort being put into WPF right now (some of it mine), but we only have so much we can do at once.

I almost missed this request for WPF grievances! What about simple things like this http://stackoverflow.com/q/11477821/466011 that turn out to be much harder than they should be? Or have things changed since I posted that question almost 3 years ago.

# ? Jul 5, 2016 04:47

raminasi: Jan 25, 2005; a last drink with no ice

john donne posted:

In what way is the URL of your API different than a connection string to a database? How do you provide that information to your application?

It's not really, but I don't have a database, and I've never created a web application before, so I don't know how one would go about providing a connection string to one. However, that's a good idea for a thing to google.

AWWNAW posted:

If you don't want it in source control you can provide it via environment variable, configuration server, pack it in during your build process, etc. You have many options. Unless it's going to change often or is "secret", why wouldn't you just provide it via .config?

Providing it via .config sounds great! I guess I should google what .config is.

# ? Jul 5, 2016 05:01

ljw1004: Jan 18, 2005; rum

Cryolite posted:

Is there a way to take advantage of our custom POCOs so that we can re-use them all while deserializing from XML, with preferably good performance? Is there a library that could help with this?
Or am I better off implementing it from scratch? And if that's the best option, how do I approach this? Since I don't really know much about the best way to deserialize stuff, should I just look at Json.NET's source and copy it for XML?

I step back from it and ask "what's the actual objective of POCO?"

If you're writing in Javascript then you get back a JSON object and it's just there, untyped, no deserialization needed.

If you're writing in Typescript then you get back a JSON objected and it's just there, no deserialization needed. You use a "definitely-typed" library to help you with compile-time checking that you're accessing the right fields.

What does it actually buy you in C# to deserialize everything into POCOs? Are you doing it solely for the compile-time checking and intellisense? Typescript shows another way to achieve that. F# type providers too. I wonder if there are other ways as well?

# ? Jul 5, 2016 05:47

Mister Duck: Oct 10, 2006; Fuck the goose

Ok I'll try to go through everything I just talked about with the team.

Open Source - We've chatted about this among ourselves several times and we'd be excited to go down that road. However, that's not something the engineering team itself can just embark on. This may be an obvious and unsatisfying answer, but the higher up business level people need to give us that sort of mandate. UserVoice can help, but this is a very large/complicated request. So while I would suggest continually upvoting that, there are overarching concerns there.
OneWayToSource with Read-only Props - Went back to check out if there were any reasons and talked to the, basically, data-binding dude. Turns out that we haven't officially rejected that (sorry for the incorrect info before) but it's been pushed off a bunch of times in the past for various reasons (not all of which I know). The general gist is he'd love to change it but we need much more support for it from the outside in order to make it a priority over other things being tackled. So get thee to UserVoice and start upvoting or filing requests (please use this one).
MVVM Improvements - I am using this as a catch all for adding bits from MVVM Lite, PRISM, and generally making MVVM less of a hassle in WPF. The same applies as above. Make sure your issues are on UserVoice and brigade the hell out of them. Try to spend some time searching for stuff that parallels what you want an upvote rather than filing new very specific requests. This is definitely floating in the air for the next version, but if you want this realized we have to have more support for it in places where the leads can see (again with UserVoice/Connect).
Decimals in textboxes with PropertyChanged semantics - I realize this is a tough issue (I've had to deal with basically the same thing in the past). There is a flag that can possibly help to alleviate your issue. I know when I did it I had to implement a formatter + a behavior to correct caret position, but I was ignorant of the flag and behavior change from 4.0->4.5.
Touch Support - Can you tell me specifically what has you turning off touch? I assume by turning off you mean the private reflection hack to kill the Tablets (I get chest pains every goddamn time I see that MSDN page). I know the stack has issues (believe me I know) and I am hoping to alleviate them by modernizing what we depend on for touch data. But I can try to help anyone who has issues right now if I can get a handle on the exact problems. At the very least I can make drat sure that mistake isn't made again in the new code.
Theming - I take it that the complaints over control polish and looking like basic Win32 controls are concerned with our updates (or lack thereof) to themes post Win7. We've discussed doing these changes to bring the possibility of alignment with UWP look and feel (as much as possible) especially considering that Win32 (WPF included) applications will now be allowed in the store. I don't believe it is currently being worked on however. As above, priority can be helped with UserVoice votes.

So not as satisfying as seeing "all of your issues are now going to be fixed!", but I wanted people to know there is effort being put here even if it doesn't always align with their wishes.

Let me try to frame this from my perspective as someone who recently started at MS and on the WPF team and spent a few years writing WPF applications prior. There is a renewed effort to fix and improve things in WPF. I realize that in the past you might have felt ignored and disappointed with feedback channels, etc. We're trying to change that. Obviously we cannot fix everything or implement everything that people want. We're bound in some fashion to concentrate on issues and trends we see coming from high profile customers and people who have servicing agreements with us. Combing sites like StackOverflow is a huge drain on time that we don't really have. I am here solely because I've been semi-lurking SA for years and, given my current position, I don't like to hear people feeling completely pissed off at something that I've grown to love working on. So I will be as helpful as I can when I can and maybe that won't be as useful as it should be, but please know that there are people working on WPF and we're really trying to make headway to modernize what we can.

That being said, older issues that you may have filed on UserVoice or Connect that were closed or you can no longer find or something, feel free to open them again. A lot of things that may have been closed due to time or focus constraints in the past now are more open to the team and we need to have that outside push renewed so we can argue for priority.

My lead is out right now, but I am going to see if we can get some summary of what we're currently working on and push it out to the public. If, hopefully when, we do I will definitely link it here. I've been trying to get a greater effort to have a new public face on WPF in general but it hasn't materialized just yet. I'll use your feedback as fuel to the fire.

# ? Jul 5, 2016 20:12

epswing: Nov 4, 2003; Soiled Meat

Mister Duck posted:

You are a marvelous human, Mister Duck. Thank you for your efforts.

# ? Jul 5, 2016 20:16

100 degrees Calcium: Jan 23, 2011

So my team has a new web application project coming up and one of the members brought up the possibility of using .NET Core for it. Currently all of our projects are in .NET 4.5. This might be a dumb question, but is .NET Core, as an open source framework, a parallel branch off from .NET, or is it "the next version"?

I dunno if that makes any sense. Basically I'm trying to figure out if we're looking at a continuation of the .NET framework seperate from Core.

# ? Jul 5, 2016 20:26

raminasi: Jan 25, 2005; a last drink with no ice

Mister Duck posted:

Honestly, just hearing that WPF hasn't been left to die is a pleasant surprise.

Now whom do I talk to about the fact that UserVoice won't accept my vote? :v:

"We couldn't submit your vote at this time."

# ? Jul 5, 2016 20:27

Mister Duck: Oct 10, 2006; Fuck the goose

raminasi posted:

Honestly, just hearing that WPF hasn't been left to die is a pleasant surprise.

Now whom do I talk to about the fact that UserVoice won't accept my vote? "We couldn't submit your vote at this time."

That's just the universe telling you to not listen to me.

I just voted up a few things on there that were mentioned here just as a test and it seemed to be happy to take my votes. Try again in a bit and if it doesn't work I'll see if anyone can give me a good contact for support there.

# ? Jul 5, 2016 20:37

Cryolite: Oct 2, 2006; sodium aluminum fluoride

ljw1004 posted:

I step back from it and ask "what's the actual objective of POCO?"

If you're writing in Javascript then you get back a JSON object and it's just there, untyped, no deserialization needed.

If you're writing in Typescript then you get back a JSON objected and it's just there, no deserialization needed. You use a "definitely-typed" library to help you with compile-time checking that you're accessing the right fields.

What does it actually buy you in C# to deserialize everything into POCOs? Are you doing it solely for the compile-time checking and intellisense? Typescript shows another way to achieve that. F# type providers too. I wonder if there are other ways as well?

It's an existing package that is in use by multiple teams across the company. Deserializing into the same types without changing them buys the significant value of not making breaking changes to code that is already in use. It's a data contract now and I'd like to get the performance gain using the same types so that I don't break that contract and so that other people will actually use the package, otherwise there'll be a high barrier for upgrading and we may have to change a ton of code. I need to be backward compatible. Adding attributes to classes isn't a huge deal, but completely changing how the wrapper is consumed is bad.

# ? Jul 5, 2016 22:10

Mr Shiny Pants: Nov 12, 2012

Mister Duck posted:

Great info

Thanks man, that is good to know.

And yes, I mean some really polished controls would go a long way to make apps look a lot better for users.

# ? Jul 5, 2016 22:19

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

GlitchThief posted:

So my team has a new web application project coming up and one of the members brought up the possibility of using .NET Core for it. Currently all of our projects are in .NET 4.5. This might be a dumb question, but is .NET Core, as an open source framework, a parallel branch off from .NET, or is it "the next version"?

I dunno if that makes any sense. Basically I'm trying to figure out if we're looking at a continuation of the .NET framework seperate from Core.

AFAIK there will be parallel development of the two. .NET Core literally just came out and has some rough spots and 1.0isms especially around support for popular third-party libraries. It's cool and new, but that doesn't mean it will be successful (although it probably will be), and it's definitely not as robust/supported.

Look into it and evaluate if it can do what you need it to do TODAY. If it can, go for it. If it can't, don't use it yet.

# ? Jul 5, 2016 22:31

Inverness: Feb 4, 2009; Fully configurable personal assistant.

I remember reading a blog post some time ago about the WPF team abandoning their app-local (nuget package) intentions for WPF. I think it mostly had to do with greatly increased startup time due to a lack of native images being available when the libraries are deployed with an app.

I'm not sure if this even still applies. NuGet has ways of having native libraries now.

It is relevant because the app-local deployment was seen as the first step towards an open source WPF.

# ? Jul 6, 2016 00:03

Mister Duck: Oct 10, 2006; Fuck the goose

Inverness posted:

I remember reading a blog post some time ago about the WPF team abandoning their app-local (nuget package) intentions for WPF. I think it mostly had to do with greatly increased startup time due to a lack of native images being available when the libraries are deployed with an app.

I'm not sure if this even still applies. NuGet has ways of having native libraries now.

It is relevant because the app-local deployment was seen as the first step towards an open source WPF.

App-local has pretty much been shelved for now. We still have the work that was done sitting around, but there is no push to further it as of right now. You can see the last update on that here in the first paragraph. Something of the magnitude of open sourcing would probably require more ramp up in people just to keep the same bug velocity while getting it all done. In any case, I'll keep raising that as something we'd like to get done in some capacity on the team, but like I said it's going to need top down support from .NET on the business side.

The next-next version of WPF (I am talking .NET 4.6.3 or whatever number it may be when it comes about) has some pretty clear goals spread to the team right now. So mostly each team member has one major feature we are attempting to get done all while squashing as many servicing issues as we can. I talked with my PM today about getting out more information to the public. Probably once .NET 4.6.2 releases with Win10 RS1 we'll turn toward publicizing what we expect out of our next preview version.

Just to make sure everyone has seen the current release that is pending (.NET 4.6.2) the two major WPF changes are touch-keyboard support and framework support for per-monitor DPI (see the rest here). Both require Windows 10 RS1 (Anniversary Edition). And as I said before, I'll be publishing some code that will help people in cases when the touch KB occludes controls.

# ? Jul 6, 2016 04:52

EssOEss: Oct 23, 2006; 128-bit approved

What is the latest and greatest "right way" to make a .NET library that works on UWP, .NET Framework, .NET Core and Xamarin? In terms of project and NuGet package structure. I especially wonder about things like CPU architecture and so forth.

EssOEss fucked around with this message at 12:57 on Jul 6, 2016

# ? Jul 6, 2016 07:57

amotea: Mar 23, 2008; Grimey Drawer

Thanks for the great info Mister Duck, and for dealing with ranting posters

.

I understand the bigger stuff has to be decided higher up, I'm just curious how this works in a big organization like MSFT. How high up are we talking? Is it like the top management that decides they want to move towards e.g. UWP/Apps/Phones etc? Or is it more like a middle-level manager that oversees .NET/Desktop development?

# ? Jul 6, 2016 12:11

Mister Duck: Oct 10, 2006; Fuck the goose

amotea posted:

Thanks for the great info Mister Duck, and for dealing with ranting posters .

I understand the bigger stuff has to be decided higher up, I'm just curious how this works in a big organization like MSFT. How high up are we talking? Is it like the top management that decides they want to move towards e.g. UWP/Apps/Phones etc? Or is it more like a middle-level manager that oversees .NET/Desktop development?

The general drives are company wide. So backing UWP as the next thing requires cooperation between several organizations and groups. We're talking .NET (and the whole of the DevDiv org), Windows, and a lot of other pieces of SW like Office, etc. So no way anyone not at the top of the food chain could make that decision. It takes a lot to decide to not support something, hell we still have teams supporting WinForms and old apps that came with Windows. It's hard to appreciate the scope of backward compat that MS strives for until you see the amount of cash that is thrown at it. It pales in comparison to new stuff, but it's bigger than entire dev orgs of smaller companies. This is another reason that it's fun to read all the conspiracy theories about Win10. People dismiss the fact that everyone on a single version of Windows saves the company insane amounts of cash and time. Although I won't pretend I don't send snide messages to the nag screen guy every time I read an article that derides it.

Anyway, I really appreciate everyone giving feedback here and I hope we can cover at least a few complaints in the next version.

# ? Jul 6, 2016 15:25

Mr Shiny Pants: Nov 12, 2012

Just for my curiosity, but does the Office team use your tooling now or do they still use their own widgets?

One of the problems with WPF is that only the VS team uses it internally making it a bit of a underdog.

# ? Jul 6, 2016 16:00

Drastic Actions: Apr 7, 2009; FUCK YOU!
GET PUMPED!; Nap Ghost

My go to example for why WPF was so good and being underutilized was the Zune app. I really loved that apps design and look, and wished more apps could be written like it. Then Miguel told me it was all custom and not WPF at all, and I was like :aaaaa:

# ? Jul 6, 2016 16:12

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Mr Shiny Pants posted:

Just for my curiosity, but does the Office team use your tooling now or do they still use their own widgets?

One of the problems with WPF is that only the VS team uses it internally making it a bit of a underdog.

I'd be pretty surprised if Office adopted WPF. Even if the antitrust things are no longer a concern and they legally could take on a hard dependency on .NET, the team has always been incredibly opposed to having any dependencies.

# ? Jul 6, 2016 17:38

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Mister Duck posted:

Although I won't pretend I don't send snide messages to the nag screen guy every time I read an article that derides it.

Funny you should mention that thing. After begging me for months to upgrade my home desktop because of all the benefits of 10, it's begun negging me by telling me I can't upgrade because of the backup software I installed :lol:

# ? Jul 6, 2016 17:39

Mister Duck: Oct 10, 2006; Fuck the goose

Mr Shiny Pants posted:

Just for my curiosity, but does the Office team use your tooling now or do they still use their own widgets?

One of the problems with WPF is that only the VS team uses it internally making it a bit of a underdog.

Office is pretty much its own animal apart from WPF as far as I know. The add-ins for office that you write in .NET (VSTO) can technically use WPF to plug into various things and display UI but that's another bag of worms.

Other teams in MS do use WPF, it's not just VS. But sure, the highest profile project around for it is VS (and they do drive a lot of improvements). Also, although these are usually simple and mostly hated, a lot of out of box stuff from OEMs like update clients and things use WPF. I think our biggest users are still in the enterprise world (in terms of feature use, not distribution). We see a lot of usage on embedded PoS and control systems as well. Hopefully we'll get better telemetry as people move to Win10 to really understand what people do with WPF in terms of feature usage.

It is amazing to see an error report that tells you millions of people a day are crashing. The numbers and variety of HW configurations are pretty staggering at first. I am still amazed at the Windows kernel for being able to support so much legacy stuff across so many variations of hardware for decades. Windows has its issues, but goddamn is it a marvel of engineering in a lot of ways. It just makes you really respect people like Raymond Chen and Mark Russinovich. EDIT: for not mentioning Dave Cutler, goddamn.

Drastic Actions posted:

My go to example for why WPF was so good and being underutilized was the Zune app. I really loved that apps design and look, and wished more apps could be written like it. Then Miguel told me it was all custom and not WPF at all, and I was like .

Zune is quite before my time, I've only been here a little more than 2 years. I never personally had a Zune. At the time I had one of the bigger iPods so I could store everything I had on one device. But holy poo poo am I glad those died out as a thing and I never have to use iTunes ever again.

Mister Duck fucked around with this message at 18:03 on Jul 6, 2016

# ? Jul 6, 2016 17:49

Mister Duck: Oct 10, 2006; Fuck the goose

Plorkyeran posted:

I'd be pretty surprised if Office adopted WPF. Even if the antitrust things are no longer a concern and they legally could take on a hard dependency on .NET, the team has always been incredibly opposed to having any dependencies.

This is a good point too. Office is for like every platform ever these days. Keeping the code base in good cross-platform order pretty much precludes a .NET dependency at this point.

# ? Jul 6, 2016 17:50

Mister Duck: Oct 10, 2006; Fuck the goose

Munkeymon posted:

Funny you should mention that thing. After begging me for months to upgrade my home desktop because of all the benefits of 10, it's begun negging me by telling me I can't upgrade because of the backup software I installed

Easiest thing there is check for an updated version that supports 10 and remove the current version, update, then re-install. That might even work just for the same version you have right now. The whole update and compat process is a black box to me, I've never looked at the code, nor would a cursory glance really inform me of much. I can't even begin to imagine the tedium of checking as many configurations as we could. Statistically it's been amazing though how little issues have come about from the 300 million+ users.

# ? Jul 6, 2016 18:00

ljw1004: Jan 18, 2005; rum

EssOEss posted:

What is the latest and greatest "right way" to make a .NET library that works on UWP, .NET Framework, .NET Core and Xamarin? In terms of project and NuGet package structure. I especially wonder about things like CPU architecture and so forth.

Here are the two guides available so far:

https://docs.microsoft.com/en-us/dotnet/articles/core/tutorials/libraries
https://docs.microsoft.com/en-us/dotnet/articles/core/tutorials/target-dotnetcore-with-msbuild

# ? Jul 6, 2016 18:18

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Mister Duck posted:

Easiest thing there is check for an updated version that supports 10 and remove the current version, update, then re-install. That might even work just for the same version you have right now. The whole update and compat process is a black box to me, I've never looked at the code, nor would a cursory glance really inform me of much. I can't even begin to imagine the tedium of checking as many configurations as we could. Statistically it's been amazing though how little issues have come about from the 300 million+ users.

Yeah, it'll just add a step to the process or, rather, it'll make that step easier to find and do preemptively. I just thought it was hilarious that it went from telling me how great 10 is and how much I'd love it to "you can't have it :smuggo:

" Really, it should have told me that from the beginning because I've heard about some of the cryptic installation errors, which would be significantly more frustrating. Friend of mine tried to upgrade and got one of those stupid hex codes that he had to google to find out there were too many USB drivers installed or something? He just gave up, I think.

# ? Jul 6, 2016 18:31

Adbot: ADBOT LOVES YOU

# ? Jun 10, 2024 20:21

Mister Duck: Oct 10, 2006; Fuck the goose

Munkeymon posted:

Yeah, it'll just add a step to the process or, rather, it'll make that step easier to find and do preemptively. I just thought it was hilarious that it went from telling me how great 10 is and how much I'd love it to "you can't have it " Really, it should have told me that from the beginning because I've heard about some of the cryptic installation errors, which would be significantly more frustrating. Friend of mine tried to upgrade and got one of those stupid hex codes that he had to google to find out there were too many USB drivers installed or something? He just gave up, I think.

Yeah, when I first saw the whole "Something Happened" error scenarios pop up I just shook my head. I mean sure, a normal user has 0 idea what to do with almost any error, but at least provide some detail there so random internet people can get a clue. Not that there aren't cryptic errors in WPF either. I've had a couple of PC Load Letter moments even with full access to stuff. (Anyone ever see a SyncFlush error bubble up in WPF? Good loving luck.)

# ? Jul 6, 2016 19:01

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > .NET Megathread 3.5: await GetGoodPosts()

«‹›300 »