Dotnet: Solution to the "Localized exceptions" problem

[mlsomers]

The problem is well known and there are some workarounds available. Previous requests for a structural fix have not received much attention.

A preferred solution would be to have an app.config element (I suggest adding it to the runtime element) that would enable us to get non-localized messages in a specific deployment (e.g. on a developers machine).

Another approuch could be to add a new property to the Exception class called MessageNonLocalized (to keep it near Message in intellisense). Also update the ToString method to use that message instead of the localized one. (ToString() also adds the stacktrace, so this is for developers any way).

I know that we may be able to write extension methods or other workarounds, but jumping through a hoop whenever trying to debug some code can become tiresome, especially if it's not your own code or just an open source sidekick.

[CzBuCHi]

wut? i think i sah this type of request 8+ years ago .... and we still needs to translate exception messages to english?

PS: I personally DO NOT understand any of localized exception messages despite theyre written i my native language ...

PSS: At least give us identifier string, that is used as key in resx file, so we can google that instead of jiberish like "Tento typ CollectionView nepodporuje změny své kolekce SourceCollection z jiného než dispečerského vlákna." if english messages arent present on local machine...

[Hi-Angel]

I shall say, I don't use .NET much nowadays, but in case it's useful mono always does print english messages:

$ LANG=ru_RU.UTF-8 mono test.exe

Unhandled Exception:
System.IndexOutOfRangeException: Index was outside the bounds of the array.
  at HelloWorld.Hello.Main () [0x00007] in <69eb3976d7534e8dae611f6b1ae97a34>:0 
[ERROR] FATAL UNHANDLED EXCEPTION: System.IndexOutOfRangeException: Index was outside the bounds of the array.
  at HelloWorld.Hello.Main () [0x00007] in <69eb3976d7534e8dae611f6b1ae97a34>:0

I remember a year ago Mono wasn't, say, perfect, but it is sponsored by Microsoft, so hopefully it get (already got?) better.

[CzBuCHi]

yea ... IndexOutOfRangeException, NullReferenceException, KeyNotFoundException and maybe others arent translated at all ... but these dont even need message to figure out whats wrong.

BTW: at least for MsBuild-realted exceptions i managed to turn them to english by deleting all lang-related folders in c:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\
with works until visual studio update, when installer downlaods these folders again ...

[artemious7]

@CzBuCHi

yea ... IndexOutOfRangeException, NullReferenceException, KeyNotFoundException and maybe others arent translated at all ... but these dont even need message to figure out whats wrong.

They DO need to be English. When I send my exceptions to Google Analytics (or other cloud service), I will have different groups of exceptions for the same exception, but different languages. And I will not be able to sort by count of each exception, because it doesn't reflect the real count (100 in English, 77 in Chinese, 80 in Korean... etc).
And figuring out each time which of the localized messages are which exceptions is a pain in the butt.

[richlander]

PTAL @terrajobst @tarekgh

[tarekgh]

In general, we don't recommend taking a dependency on the exception messages as these can change at any time even if they are English. Usually, we recommend depending on the exception itself and not the message. We have some cases (e.g. .Net Native) can optimize for the desk size and not include any exception messages.

It is not clear to me what exactly the scenario you are trying to make it work? why you want the messages in English while the user set their Language to something else?

I understand the debugging scenario, but this can be easily worked around by setting the UI culture to English as this will not affect the real user. and even if you have a localized message, you may use any machine translation to get the English translation. but I am not sure what exactly the other scenarios like what @artemious7 mentioned. what analysis needs to be done with the exception messages? and why?

[CzBuCHi]

only time our user actually see exception message is when that exception is unhandled, all other cases we showing our own message instead with context specific information (and hidden stack trace) with ability to send real exception message and stack trace via mail - and in that case non-english expection message is pain in the rear end because 99% of answers on internet about that exception are in english (and that 1% is about how to translate it to english)

[mlsomers]

@tarekgh the problem is not only for programmers who can indeed use a workaround (which is quite a hassle by the way). Administrators also heavily suffer from this. So much so that workarounds like http://www.unlocalize.com/ have been developed. When logging errors anywhere, the english version is much more desirable.

You say we should use the exception itself, well it can indeed be serialized, but then you need to make a tool that can un-serialize them again (and add all possible exception types must be declared beforehand in [XmlInclude(typeof(MySpecialException))] attributes for the collection containing them... totally unrealistic).

As I said before, I'd advocate for a new <runtime> sub-element in the app.config which we or any administartor can have control on how exceptions are rendered.

[tarekgh]

@CzBuCHi

only time our user actually see exception message is when that exception is unhandled, all other cases we showing our own message instead with context specific information (and hidden stack trace) with ability to send real exception message and stack trace via mail

Why don't you do the same for the unhandled exception as you are doing with the other exceptions? I mean you can subscribe to the unhandled exception event https://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception(v=vs.110).aspx?

@mlsomers

You say we should use the exception itself, well it can indeed be serialized, but then you need to make a tool that can un-serialize them again (and add all possible exception types must be declared beforehand in [XmlInclude(typeof(MySpecialException))] attributes for the collection containing them... totally unrealistic).

you don't need to do that. you can just capture the exception class name and the stack and use them as strings so you can do whatever analysis you are doing today with the exception messages. I think this can give you more reliable way in the analysis than just the exception message.

As I said before, I'd advocate for a new sub-element in the app.config which we or any administartor can have control on how exceptions are rendered.

Exceptions take the message strings as a parameter. so you cannot control this for the exceptions only as you cannot guarantee the source of the message strings. And even if we have a way for the framework exceptions we'll not have a way for non-framework exceptions. To be able to have a uniform way to force the English language for getting the exception message is to force the whole app to use English UI culture which I believe the apps can do that as needed and the users can do that by running on English UI.

[CzBuCHi]

@tarekgh quick look at random framework code i see this:

throw new SerializationException(Environment.GetResourceString("Serialization_NoID"));

ony thing that i ask is that exception object will have extra property witch in this case will have value "Serialization_NoID" - that way when this exception occurs i can show user translated message and i can search for "SerializationException Serialization_NoID"

ofc this will work only in framework code ....

[tarekgh]

@CzBuCHi although Environment.GetResourceString is used mostly to get the exception message resources inside the core assembly (e.g. mscorlib.dll), Environment.GetResourceString is not restricted to the exception messages. it is used to get the resources in other scenarios. one example is here:

https://referencesource.microsoft.com/#mscorlib/system/globalization/culturedata.cs,1192

Also, in none-core assemblies Environment.GetResourceString is not used because it is internal to mscorlib. and instead, a direct instance of the ResourceManager is used to get the resources which is not restricted to exception messages too.

https://referencesource.microsoft.com/#System.Xml/System/Xml/Core/XmlReaderSettings.cs,382

[CzBuCHi]

@tarekgh What i mean is provide use some property that will identify that exception - dont care if it is key to resx or some crazy UINT64 value - only thing thas important thats this identifier would be unique and language independent and therefore easily searchable on forums ...

[tarekgh]

@CzBuCHi isn't the exception type and the stack can uniquely identify the exception?

[mlsomers]

@tarekgh you do have a point that the message is quite dynamic and you can't always have control, so that does complicate stuff I agree. Ironically that also means that the exception type and stack cannot specifically identify an exception.

An ArgumentException can be thrown for any of multiple arguments on a method, so the Message part is often essential. I personally often add some contextual info into the message, for example a I wrap a FileNotFound exception in order to specify the filename and path in the message (putting the original one in the InnerException).

Looks like we'll have to mess around with the workarounds then, but can't we at least have a standard workaround in the framework? An extension method on an exception that temporarily changes the thread Locale could kind-of work in my main projects. But when working on multiple projects for different customers or open source stuff, it's a real hassle to drag along a bag of code snippets. In 3rd party applications my hands are bound (unless I go down the decompiling and hacking route).

In my ideal world, administrators should also be able to temporarily change the thread locale when exceptions occur without having to depend on coders adding workarounds. It would enable them to solve many problems that now come my way because they do't have a clue, and neither does Bing.

[tarekgh]

An ArgumentException can be thrown for any of multiple arguments on a method, so the Message part is often essential.

Actually what is useful is the values inserted in the message. for example, in Argument exception, it is the argument name which you can still get it from the ParamName property from the exception object.

I am not pushing back on any idea here but I wanted to clarify that supporting English messages only wouldn't be trivial for the reasons I mentioned early, in addition, the admins would need to opt-in to whatever mechanism anyway. and if they do, they can force running on English cultures.

Does it help if provide a tool that can take the localized message and return the matched English text? I am just brainstorming the ways that may help. or having a spreadsheet have all messages in all supported languages for easier search?

[mlsomers]

@tarekgh It's not a problem that admins need to opt-in, as long as they can do so without the developer having to provide the means explicitly in advance.

It is clear that it will not be trivial, I fully appreciate that. Especially if a custom exception overrides the Message property or the ToString() method and uses resource files, while no English resources exist... You will have to try not to throw new exceptions while handling, and fallback to the original locale if such conditions occur. Still it would be a great relief if the framework could provide this service in a generic way where administrators can opt-in without any code change.

By the way, I really dislike exceptions that add new properties for specific info. In order to make some generic code that logs all unhandled exceptions, you need to use reflection or so to detect these extra bits of info (no one hardly ever bothers). For example the EntityValidationErrors on a DbEntityValidationException are hardly ever logged. When adding the info to the message you can be relatively sure that it will be logged (it saves allot of $$$ when something can solved without the need to reproduce the error).

Providing a tool as you suggest is what http://unlocalize.com/ has been trying to do for years (they don't seem to have been very successful though).

[tarekgh]

It's not a problem that admins need to opt-in, as long as they can do so without the developer having to provide the means explicitly in advance.

The admins can opt-in running on English UI and would get the English exception messages (in most cases). so the developer doesn't need to provide anything. I understand some cases the app sets the UI culture but this is not common cases though.

[mlsomers]

@tarekgh Can you provide the steps to run an application on English UI on a non english OS? I'd love to do that on my development machine, but all attempts so far have failed.

Look, you're not in any way obligated to fix anything, but denying the problem is not helping anyone.

[tarekgh]

Can you provide the steps to run an application on English UI on a non english OS

• press Windows key + I
• click on Time & Language
• click on Region & language

Then ensure English is the default Windows display language.

Look, you're not in any way obligated to fix anything, but denying the problem is not helping anyone.

As I mentioned before I am not really pushing back. To support what you are asking is not trivial (and even not possible in some scenarios, e.g. third parties exceptions or exceptions in .net native). In the same time, I am seeing this is not the main scenario will be needed by the majority of apps while there are workarounds as discussed in this thread.

[svick]

What i mean is provide use some property that will identify that exception - dont care if it is key to resx or some crazy UINT64 value - only thing thas important thats this identifier would be unique and language independent and therefore easily searchable on forums ...

I my opinion, the right solution is to add a property that provides the English message (it could be called e.g. InvariantMessage). The information required to fill that already exists and shouldn't be hard to access. And it would mean that 3rd party libraries that also localize their exception messages (do those even exist?) could fill that property too.

Even better: Exception.ToString() could include both Message and InvariantMessage, so if someone posts their exception text somewhere, you can always understand the message, even if they have different UI culture.

(I now reread the original post and realized that what I just said is effectively the same thing that was proposed there.)

[svick]

@tarekgh

It is not clear to me what exactly the scenario you are trying to make it work? why you want the messages in English while the user set their Language to something else?

Because the user and the person trying to diagnose the exception may not be the same person. Some specific examples:

1. A beginner programmer with non-English UI language asks an exception-related question on Stack Overflow and I want to help them.
2. A user of my application or my library (with non-English UI language) requests help with a framework exception.

In both cases, asking for them to switch their UI language is probably not reasonable. (The user in case 2 might not even speak English.)

Translation is usually possible, but the results are not ideal ("Is this message the same one I'm familiar with in English, or is it subtly different?") and I think it's unnecessary work.

[CzBuCHi]

Maybe save it and send to developers? And show client some more generic one?

Dne 22. 11. 2017 19:52 napsal uživatel "Petr Onderka" <
[email protected]>:

@tarekgh https://github.com/tarekgh

It is not clear to me what exactly the scenario you are trying to make it
work? why you want the messages in English while the user set their
Language to something else?

Because the user and the person trying to diagnose the exception may not be
the same person. Some specific examples:

1. A beginner programmer with non-English UI language asks an
   exception-related question on Stack Overflow and I want to help them.
2. A user of my application or my library (with non-English UI language)
   requests help with a framework exception.

In both cases, asking for them to switch their UI language is probably not
reasonable. (The user in case 2 might not even speak English.)

Translation is usually possible, but the results are not ideal ("Is this
message the same one I'm familiar with in English, or is it subtly
different?") and I think it's unnecessary work.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/dotnet/issues/474#issuecomment-346442040,
or mute
the thread
https://github.com/notifications/unsubscribe-auth/AL3kAXzjAPIzEpeSSh-f7ForXAKtVvAaks5s5G1_gaJpZM4PQ13v
.

[tarekgh]

@svick Adding InvariantMessage or Exception.ToString() wouldn't help either with the existing code. it may help a little in the future.

For the exception object to get the invariant message would need a way to do that. The exception class doesn't read the messages at all, instead, it is just passed through the constructor (e.g. new Exception("The message")). To apply your suggestion will need to expose other Exception constructors which takes the invariant message too (e.g. Exception(string message, string invariantMessage)) and then you have to have the callers who create the exception to pass the 2 messages. All existing code wouldn't get the invariant message anyway. Also, if devs don't care about the invariant message they will not use the new constructor. am I missing anything here?

[svick]

@tarekgh

Adding InvariantMessage or Exception.ToString() wouldn't help either with the existing code

It would help with existing user code, as long as it's run on a new framework.

All existing code wouldn't get the invariant message anyway.

Yeah, all framework code that throws exceptions would have to be updated.

am I missing anything here?

Other than the above, you're not missing anything, what you described is pretty much how I imagine it would work.

[tarekgh]

@svick still there would be concerned with that. we'll not be able to force all none-framework libraries to do the same. look at NuGet and you will see a lot of the libraries there would need to update too. Also, there will be a perf concern as throwing the exception will require retrieving the messages twice. While I can see when this is useful, but I am still seeing this is not the main scenario. even devs run into that would just be able to get the translation from any machine translation sites. for devs who need to do analysis, the exception type and the stacks would be more interesting than the messages itself.

[svick]

@tarekgh

look at NuGet and you will see a lot of the libraries there would need to update too.

Do NuGet libraries actually use localized exception messages? I don't recall ever seeing that outside of libraries created by Microsoft.

[tarekgh]

@svick nothing can prevent the NuGet to have localization https://docs.microsoft.com/en-us/nuget/create-packages/creating-localized-packages

My point is, there is a lot of written code today and it doesn't make sense to ask for updating all that code to do what you have suggested. Also, I have mentioned the perf concern with this approach too. The scale of the change for all framework libraries will be huge too while this is not really a common scenario.

[CzBuCHi]

@tarekgh frankly i dont care about some nugets ... i just wanna exception to have something, that can be directly posted on forums ... (and becase most of them are english forums english message would do the trick)

BTW: How hard this can be done in .NET Core? - maily because (as i understood) is .NET rewrite from scratch and therefore dont suffer with 'backwards compatibility issue' ...

[tarekgh]

How hard this can be done in .NET Core?

It is not hard but it is a huge change, in addition, there is perf concern with this approach. at the same time, the real applications are not going to benefit from it.

mainly because (as i understood) is .NET rewrite from scratch and therefore dont suffer with 'backwards compatibility issue'

Although we may accept some breaking change in net core, we are trying to to be compatible with the full framework because we need to have the libraries behave the same if running on net core or on the full framework.

I am seeing the scenarios mentioned here mainly for diagnostic purposes and can be achieved by offline tools (or even writing a small helper class that can send the localized message to any translation service and gets the English one).

[ericnewton76]

[quote]I am seeing the scenarios mentioned here mainly for diagnostic purposes and can be achieved by offline tools (or even writing a small helper class that can send the localized message to any translation service and gets the English one).[/quote]

You're kidding right? Most of the translators have trouble with normal speech, much less technical jargon!

I'll throw my two cents in on this.

Theres really a few problems with the .Net Exception type model:

• Too many exceptions have too-flat of a type model, like System.Data.SqlClient.SqlException
• Localization of message thwarts using message as the discriminator for specializations like SqlException
• Extra property's data on specialized Exception types gets lost on specialized classes like SqlException and DbEntityValidationException

I agree that some exceptions thrown from the framework are well typed, meaning that specific issues get more specific exceptions. ArgumentException and derivations are a good example. However, there's that other percentage of exceptions that should definitely have had a more specific type, but seems to have suffered from the "they can figure out exactly from the message part" or the ErrorCode. However there's a large amount of "grab bag" type of exceptions lumped into one type, but each actual problem are different.

An example, a SqlException seems to be thrown for practically everything from client connection problems to the server itself returning a fatal error. Some would say "the specific problem is the message." Um, yeah, that's what we're talking about... was it a client connection failure or just the server saying the column didnt exist on the table? SqlException does include an int ErrorCode property, but again suffers from not dumping that into Exception.Data and gets lost if the logging framework doesnt specifically know about it.

[quote]For example the EntityValidationErrors on a DbEntityValidationException are hardly ever logged.[/quote]. The System.Exception.Data property has existed since v1.0 of the framework, yet nobody on the framework team evangelized (and enforced) having extra properties making it into this grab bag.
This Data property should have every single "new property", that doesnt exist on System.Exception, stuffed in there. I'd actually recommend a two property tuple as the value: the object value, and a function pointer to a function that can render that datapoint as a string for logging. Then we get actual true OOP at least, since the override ToString() specializations on derived classes falls apart from a security standpoint. Again this gets lost if the logging framework doesnt specifically know about it.

When you open source this, possible solutions become realistic.

//possible solution as possibly an Extension Method on System.Exception itself (bleh)
public string RenderExceptionData()
{
  foreach(var kvp in ex.Data) 
  { 
    //prefer function pointer
    Func<Exception,string> dataRendererFunc = kvp.Value as Func<Exception,string>;
    if(dataRendererFunc!=null) 
    {  
      try { stringBuilder1.Append(dataRendererFunc(ex)); } catch(Exception ex2) { /*and so on*/ }
      continue;
    }
    //check if a collection, call ToString on each item
    //etc
    //etc
  }
}

When the fellow asked for a new constructor that uses instead of message, but uses a discriminator or resource key, I began thinking of something like an additional ctor on base Exception that instead of taking "string message", it would instead prefer a ResourceIdentifier type that could then help to de-localize the exception message... effectively taking all of this code:

//given this:
public struct ResourceIdentifier
{
   public ResourceIdentifier(string resourceId) { this.ResourceId = resourceId; }
   public string ResourceId { get;set; }
}
//change all these:
throw new (Argument|Net|etc)Exception(Environment.GetResourceString("Serialization_NoID"))
//to this:
throw new (Argument|Net|etc)Exception(new ResourceIdentifier("Serialization_NoID"))

//then Exception.Message property is modified to call return Environment.GetResourceString(this.Resource.ResourceId);

//specializations override Message property to supply their own resource manager

One could even argue, if the ResourceId is standard fare, then one could drop the heavy burden of the database of English strings for exceptions in certain cases... like small devices with limited storage, etc.

granted, fairly massive change to the underlying type structure of Exception-derived types, but at least there's hope! CLR is v4.0 now already having gone through 3 major changes to the VM. NetFramework 4.7 appears to have destabilized a lot of things already, and likely should've been NetFramework 5.0, so potentially a major opportunity has been lost. Adding the ctor with ResourceIdentifier certainly doesnt break any existing code.

NetCore gives a significant opportunity to augment a significant issue that wasn't considered back in year 2000 when Net framework was v1.0-beta

[svick]

@ericnewton76

there's that other percentage of exceptions that should have a more specific type, but seems to have suffered from the "they can figure out exactly from the message part".

.Net Core breaking change rules allow throwing a more derived exception than before. So, you might want to submit issues about specific cases where this happens to the corefx repo. If the maintainers agree with you, then you or someone else can submit a pull request. After that, .Net Core will throw the more derived exception. And hopefully, the change will also be merged back into .Net Framework.

NetCore gives a significant opportunity to augment a significant issue that wasn't considered back in year 2000 when Net framework was v1.0-beta

If you have any specific suggestions on how to improve the .Net API, you should create issues for them on the corefx repo, ideally following the API review process.

[CzBuCHi]

I am seeing the scenarios mentioned here mainly for diagnostic purposes and can be achieved by offline tools (or even writing a small helper class that can send the localized message to any translation service and gets the English one).

that 'helper class' could be extension method with this code:

public string UnlocalizeMessage(this Exception exc){
    return clientOfRestServiceHostedByMicrosoft.GetUnlocalizedMessage(exc); // or only exc.Message?
}

[mbeckenbach]

@tarekgh
Changing the windows display language helps to get english exception messages.
But it also causes lots of issues.

1. Lots of localized applications will switch to english to no matter what the user is used to
2. Some applications don't respect your number and date formatting when switching to english
3. Windows features like cortana dont work when your region is not the same as your language
4. Non-Technical coworkers often ask developers to help with something. Lots of fun with different OS languages.
5. The customer is using a german windows and the developer an english version. Lots of fun when it comes to the "can you please tell me your browser setting under menu xyz" situation

So switching the OS language is a workarround. But not a solution.

By the way:
I never understood why microsoft needs to translate every developer tool and framework. I don't know any developer - professional or not - who uses a german IDE, SQL Server or anything else related to development in German. Also there is no need to translate documentations as most of the time you simply cannot understand the translated version and have to switch to english anyway.

[mlsomers]

We had another one last week that we cannot reproduce. It sounded a bit like

The surgery is crippled while the opening is not switched on.

We finally figured out it meant something like

This operation is invalid while the window is disabled.

[vavido]

I am seeing the scenarios mentioned here mainly for diagnostic purposes and can be achieved by offline tools (or even writing a small helper class that can send the localized message to any translation service and gets the English one).

I would argue that the only purpose of exceptions is diagnosing problems, and translation is a huge unnecessary hurdle.
We use Sentry.io to report exceptions from our desktop WPF app, and while you might be able to reconstruct the actual problem from something like Uitzonderingen voor een taak zijn niet geobserveerd door op de taak te wachten of door de eigenschap Exception van de taak te openen. Als gevolg hiervan is een niet-geobserveerde uitzondering opnieuw opgetreden via de thread voor de finalizer. with machine translation and some guesswork (german and dutch are quite similar, so that helps) we also got quite a few Exceptions in asian writing systems and wasted hours on trying to figure out the actual error with no success.

On top of that, I don't really see any value in translating exceptions, if you ever show them to the end user it's just so they can copy the exception and send it to the dev team, which would probably like to have the english version of the exception anyway. Or at least define their language as the default, not whatever the user happens to speak.

[danstur]

@tarekgh Our use case seems quite common:

• We have to translate some user facing messages on the server side, depending on the user language which is sent with the request. Even if we could ask our customers to change their browser language, it wouldn't help retroactively for exceptions that already occurred.
• We log exceptions for monitoring and later analysis.
• Exceptions are for technical analysis and not for non-technical users.

Apart from 1) which is due to business constraints none of this seems particularly out of the ordinary. There's literally no value in having Chinese exception messages in this situation, while it makes debugging issues significantly more complicated.

Sure you claim that the message shouldn't matter and in theory that's a lovely idea. But I'm sure we can all agree that's not how it works in reality (I mean if that part is suspect, I can give you some great InvalidOperationExceptions with stack trace from the httpclient and you can tell me how I can figure out what's wrong without reading the message).

Some exceptions do have extra properties, which helps, but not all include those in the Data property which makes the whole thing dubious once again.

[tarekgh]

Thanks all for your feedback.

Considering we'll not be able to add any support for this in the Full .NET framework because we already shipping the last version 4.8 and we are not adding any more features there. And .NET Core framework assemblies are not localized, then adding anything there from now is not going to help. We may consider doing something in the future. Meanwhile, I would say, creating a tool which can take the localized message and returning the English message maybe the intermediate solution. I think the tool may grab all localized resources from the framework and index it somehow and then support searching the localized message (by partial parts) and map it to the English message.

[mlsomers]

Are you saying that version 4.8 will be the final full .Net framework? Microsoft is pulling the plug?

[tarekgh]

Are you saying that version 4.8 will be the final full .Net framework? Microsoft is pulling the plug?

Please look at the blog https://devblogs.microsoft.com/dotnet/introducing-net-5/ for more clarity about the future plans of the .NET in general.

[Hi-Angel]

Are you saying that version 4.8 will be the final full .Net framework? Microsoft is pulling the plug?

Please look at the blog https://devblogs.microsoft.com/dotnet/introducing-net-5/ for more clarity about the future plans of the .NET in general.

Oh, I think this is amazing. I'm confused though: if the next .NET will be the cross-platform .NET Core, then what will be status of Mono? Will it be obsolete? (I'm asking, because since MS bought Xamarin, now Mono is mainly developed by Microsoft).

[tarekgh]

@richlander could you help answering @Hi-Angel question?

[sujayvsarma]

@Hi-Angel Nowhere in the blog does it indicate that Mono is going away. Infact, it talks about taking the best features of Mono (like AOT compilation) and bringing that into .NET 5.

Also, the blog talks about a lot of work happening around interoperability between .NET 5 and Mono:

We’re in the process of making CoreCLR and Mono drop-in replacements for one another. We will make it as simple as a build switch to choose between the different runtime options.

All in all, Mono is going to be around.

[Hi-Angel]

@sujayvsarma sure the blog doesn't talk about it, that's why I'm asking. I just don't understand: why to maintain 2 different implementations of the same thing? Right now .net core is very reduced subset of .net, and isn't really useful. But if in .net 5.0 they start using the newer version of .net core, this means the newer .net core should be at least on par with .net 4.0, which in turn should make Mono obsolete.

So my question still stands.

[pedro2555]

It is really helpful when user understands an exception. it saves us a ton of debugging time.

Can you see the irony?

[Chiramisu]

We had another one last week that we cannot reproduce. It sounded a bit like

The surgery is crippled while the opening is not switched on.

We finally figured out it meant something like

This operation is invalid while the window is disabled.

LOL... that totally reminded me of a particular episode of Friends. "The One Where Rachel's Sister Babysits," a.k.a. "The One with the Thesaurus." 🤣

@Hi-Angel @sujayvsarma Fast forward to today, a few months after Build 2020 and the three pillars of the future of development will be .NET 5, MAUI, and WinUI3.

[gutyina70]

Just change Windows language to English

[Hi-Angel]

@Hi-Angel @sujayvsarma Fast forward to today, a few months after Build 2020 and the three pillars of the future of development will be .NET 5, MAUI, and WinUI3.

Meh, not pillars I'd like to rely upon.

MAUI github page says Linux is "community-supported", and judging by comments on the page you linked, no one cares about MAUI. So basically one major platform is out. Besides, I took a look at commits history, it doesn't look very active. Most of the commits were README updates, and ATM there was just one since May.

And the WinUI only supports Windows 10.

[viniciusvillas]

Windows language is set to English and I'm still seeing those very poorly-translated localized error messages. How something so simple can be such a problem for MS to solve is way beyond me.

[leecow]

This repo is no longer actively monitored. Closing up old issues that have not had activity in while. If this is still an issue, please open a new issue in an appropriate repo listed in microsoft/dotnet#1275

[cremor]

@leecow This issue had a comment just 27 days ago. How is this categorized as "old issues that have not had activity in while"?

According to #1275 open issues should have been moved to the new repo.

[leecow]

Re-opening and moving to the Runtime repo for further discussion.

[leecow]

This issue was moved to dotnet/runtime#46656