|
I just started this last night at midnight.
|
|
|
|
|
Why the "big deal"? They could call it ".NET DogPile 1.0" for all I care. It still makes me money when I write code in it...
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
If you don't care then don't comment.
I somehow doubt you've even read the petition.
Besides, with all the thousands of .NET programmers out there and the 3.2 million CP users, only 3 new threads since yesterday night on these forums. Is that a bad sign? 
|
|
|
|
|
I beg to differ. I find all 8 points on your petition rather petty...
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
Actually the eighth point is not my point, it's a reiteration of Microsoft's point. Petty? Yes, the eighth one is indeed.
Again I don't think you've read it properly. Not that I expect someone who doesn't care to read it.
|
|
|
|
|
You haven't read my post properly. I said ALL 8 points of your petition are rather petty, no just point #8.
And yes, I have read your petition properly. I just don't see what the "big deal" is... Other than "you don't like the verison number".
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
And you never will see if you keep trivializing it for yourself.
|
|
|
|
|
I don't think I'm the one "trivializing" anything here. You're the one nit picking over a VERSION NUMBER!
After reading your petition about a dozen times, I still fail to see why this is such a huge deal.
For instance. Let's take your point #5. "Mangling the .NET framework with Win32 specific API breaks that, isolating the entire framework to Windows".
Apparently you haven't noticed that this has always been true, even since version 1.0 of the Framework. The CLR and the Base Class Library, like System, System.Security, System.Runtime, System.Reflection, ..., is still intact and is NOT Windows specific, and therefore portable to other platforms, such as Linux.
Now, on top of those classes in the CLI, there are many, many, many extensions, such as the System.Windows.Forms namespace. If you haven't noticed, this namespace is VERY specific to Windows and has been around since version 1.0 of the Framework! How about the System.ServiceProcess namespace or System.Management? Same thing - Windows specific!
Adding WinFX as another set of extensions is nothing new to the expansion of the .NET Framework. Each project, like Mono, has to take the base CLI and expand on it, just like Microsoft has done with it's Windows-based version.
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
Dave Kreskowiak wrote: I don't think I'm the one "trivializing" anything here. You're the one nit picking over a VERSION NUMBER!
Uhh, no? I'm complaining about two technologies being merged into one, disrupting one's progress. I cite the version numbers because the messed up version numbers is a very good indication of the consequences to come. If it's as insignificant a matter as you say, they wouldn't have made the change in the first place.
Dave Kreskowiak wrote: Now, on top of those classes in the CLI, there are many, many, many extensions, such as the System.Windows.Forms namespace. If you haven't noticed, this namespace is VERY specific to Windows and has been around since version 1.0 of the Framework! How about the System.ServiceProcess namespace or System.Management? Same thing - Windows specific!
What they didn't do in these cases is release a new API under the same name just one year later. Windows Forms being under the System namespace is a bit unfortunate, and it is the only reason people criticize Mono for being incomplete. Alas, because it's a small portion of the .NET framework, it works. Not so with .NET 3.0, especially when they start adding more breaking CLR changes to it in the future.
There's the risk that these will depend on the past Windows-specific additions, and the version number "3.5" for the LinQ release is a good example. If the 2.0 implementation is in one directory, 3.0 another but depending on 2.0, does 3.5 depend on 3.0? See how it starts breaking down?
Point being: the guts of .NET 2.0 is portable, none of .NET 3.0 is portable, so what guarantee is there that .NET 3.5 onward will be portable at all?
Dave Kreskowiak wrote: Adding WinFX as another set of extensions is nothing new to the expansion of the .NET Framework. Each project, like Mono, has to take the base CLI and expand on it, just like Microsoft has done with it's Windows-based version.
Last time I checked, the only thing Mono added to the BCL was an additional encryption algorithm.
-- modified at 19:41 Thursday 10th August, 2006
|
|
|
|
|
reinux wrote: Not so with .NET 3.0, especially when they start adding more breaking CLR changes to it in the future.
So what did they add to the CLR to break it? What did they do that now makes it Windows specific?? Nothing! Not a damn thing! I think you're completely ignoring the modular design of the CLR, Base Class Library, and all the extensions in the .NET Framework.
reinux wrote: and the version number "3.5" for the LinQ release is a good example. If the 2.0 implementation is in one directory, 3.0 another but depending on 2.0, does 3.5 depend on 3.0? See how it starts breaking down?
Nope. And frankly, I don't care. Linq is the next generation of the language and compiler namespaces in the Base Class Library. They are non-Microsoft specific extensions that will work with other non-Microsoft database engines.
I think you're seriously confused about what parts are meant to be portable and what are not. The .NET Framework is Microsoft's Windows-based implementation of the ECMA Common Language Infrastructure. The CLI is what is meant to be portable, not the .NET Framework!
reinux wrote: Last time I checked, the only thing Mono added to the BCL was an additional encryption algorithm.
And this is Microsoft's fault how?? The Mono project is responsible for their own extensions to the BCL. Be it their own Forms namespace, or another encryption namespace. The problem with Mono is that they don't have the thousand or so people Microsoft has writing namespaces for their .NET BCL.
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
I'm starting a petition against your petition. Microsoft finally made up its mind on the names and are sticking to them. I'm happy they're finally solid on it and will not stand for your attempt to disrupt that.
Logifusion[^]
If not entertaining, write your Congressman.
|
|
|
|
|
Be my guest.
I see nothing solid about the decision, nor do I see what deciding on a new name has to do with sticking to it. If you're going to petition you'd best have a good reason for it, not just retaliation 
|
|
|
|
|
|
I have being trying to use the degree character or ring above "°C" to format Celsius, but the result is not what I want.
The following produces the degree sign, but there is a space or gap between the
degree sign and the "C" symbol.
String.Format("{0:N}\u00b0C", 20)
Currently, I have the other degree-like character "˚C", which does not produce a space between it and the "C" symbol, but the result is a bit poor on the screen:
String.Format("{0:N}\u02daC", value)
Anyone knows why this is happens? (Wow, even the result is the same in the browser)
Best regards,
Paul.
Jesus Christ is LOVE! Please tell somebody.
|
|
|
|
|
I seem to be have found the source of the problem, even though I do not know how to correct it. It is because I use a Japanese found "MS Gothic". Western fonts such as Arial, Tahoma produces the desired result.
Best regards,
Paul.
Jesus Christ is LOVE! Please tell somebody.
|
|
|
|
|
If you want to correct it, you will have to edit the font file, as it's there the error is. The 00B0 character is the correct one to use to represent degrees.
---
b { font-weight: normal; }
|
|
|
|
|
I am writing software for a company that produces a box that collects data (data and purpose are unimportant). My software is an application for users to communicate with the box (upload configuration, download data...). I am trying to design the software such that I can account for changes to the box's embedded code by adding standalone components, but not changing my core application. I merely wish to deploy components that match the new embedded code and have them automatically recognized by my software.
An example of a component is a UserControl that gathers configuration data specific for that embedded version.
Does anyone have any hints on making this easy to do? How should I package my components? How do I create them programatically? I can certainly define a common place to look for all these components, but is there a better/slicker way to store and retrieve them? Any other hints on deployment of my components?
Dave
|
|
|
|
|
Hi,
I really think that this lib is a good base for an app framework. The only problem I personally see is that you have to provide exception policiy and logging category names by string literals.
One maybe tend to use string constants, better than nothing. But .net offers reflection, so there should be a way to get all those defined policiy and logging category names at the end of the day out of an assembly, right? This makes it type safe for coding and easy to config for admins as well. Possible scenario could be to generate app.config file with each policiy and loggin category name included for a default config.
Did somebody write some attribute based code to use the Microsoft Enterprise Library features?
myMsg.BehindDaKeys = "Chris Richner";
|
|
|
|
|
|
Hi Mark,
The goal should be to retrieve all those defined names from a compiled assembly. Nobody can remember all defined names after the assembly is released, right? Imagine the defined config file get lost. In this case one have to watch in the code (MyClass.Getxx()) to make sure all defined names are configured well again. Not really handy if one is out there by a customer trying to setup the whole thing again.
That's the reason way I like this attribute based solution, one could write a small tool that uses reflection to fetch all names out of the assemblies. To generate a config file containing all defined names is just a nice to have thing, of course.
Thanks for your answer.
myMsg.BehindDaKeys = "Chris Richner";
|
|
|
|
|
Chris Richner wrote: Imagine the defined config file get lost.
Source Control 
Chris Richner wrote: Not really handy if one is out there by a customer trying to setup the whole thing again.
Sorry but I wouldn't show up at the client site without all the tools and code necessary to recreat/redeploy the application
only two letters away from being an asset
|
|
|
|
|
of course  it should just serve as an example... any way.. would be a handy thing to be able to get all cat names out of the compiled assembly... forget about the customer scenario
myMsg.BehindDaKeys = "Chris Richner";
|
|
|
|
|
Hi. I made windows hook to detect windows event in VC++.NET. And I get all mouse and key events using that. Now when we click on office word menu like FILE it create a menu window. I want to detect this menu window create event using windows hook. Pls help me to find solution. Thanks
Priyank
-- modified at 16:24 Wednesday 9th August, 2006
Priyank
|
|
|
|
|
hi there,
can I use the 2.0 framework with my Visual Studio 2003 Professional? if so, what are the problems I might encounter? any good readings about this?
thanks in advance!
/matthias
I love deadlines. I like the whooshing sound they make as they fly by.
[Douglas Adams]
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
