Pingback from » Benefit from the C# and VB.NET compilers perf
Sounds like compiler vendors need to focus their attention on linkers and librarians in terms of performance work...
Setting up a build server for your projects helps you to improve this. In fact, as soon as you have to build your projects on a second machine, you have to ensure that all the dependencies can be resolved and all the required tools are available.
If you use continuous integration, your projects don't build only on your development machine. You have already made a step in the right direction towards code mobility :-)
I completely agree with you Fabrice. The point is that not everybody know how to set up a continuous build server but everybody know how to zip a folder (hence 'simple trick').
For example, I know that in your company department a super expert is fully dedicated to set up and maintain your continous builds ;-)
This is the first I've seen somebody post about this. We have this occur in our application where fusion binding competes with the reflection binding of our business objects.
I remember spending a few hours the first time wondering why the if( myItem is MyType ) kept failing when the debugger showed the opposite. Finally found it by doing a quick watch with the Assembly.Location attribute.
Nice post
It's related to build-time and not run-time, but the "Specific Version" property on references in Visual Studio can be used to ensure that VS builds with the exact version of an assembly that you expect.
See "Specific Reference Version" in this article: www.code-magazine.com/article.aspx
At what point do you consider a programming language bloated? I am not talking about libraries that are
In C++ we call non-nullable references "references" and nullable references "pointers".
I think it's a real shame that .NET didn't adopt this terminology instead of seemingly copying Java.
I've always thought one of the biggest flaws with Java and .NET is the lack of references.
.NET references are very different than C++ pointers since there is a GC working under the hood. My point is about adding syntactic sugar to C# to avoid NullRefException.
There is a lot of buzz about C# bloat. As a developper I'm really happy to get new powerful syntactic constructs that make my code more concise. As a trainer, I have to admit that beginners get lost at first sight and it is our job to explain the intentions behind each language feature.
(Original post:)
+1
Check out Spec#:
channel9.msdn.com/.../SpecSharp.NonNull
"In this context, adding the ! syntax to C# is a bit awkward since the vast majority of references would use this extra syntax."
Yes, without the need to maintain back compatibility new languages can just take non-nullable as the default and decorate nullable types with ?
See nice.sourceforge.net/manual.html
I see i'm not the only one to have thought about it. :)
"In c#/java/c++/.. : Nullable parameters should be opt-in instead of opt-out. By default null parameters should create a compilation error if possible or throw an exception. Actually they all should have design by contract built-in the language with a nice (concise) syntax."
programming.reddit.com/.../cw8bs
Although I agree with you, I really just want an attribute that would essentially inject a null check and throw ArgumentNullException if appropriate for the specified parameter.
[NotNull("foo")]
void NoNullsAllowed(string foo) { ... }
which would essentially compile to be
void NoNullsAllowed(string foo) {
if(foo == null) {
throw new ArgumentNullException("foo");
}
which on the surface seems very much the same as NullReferenceException, but there are key differences. I've just grown tired of coding that null check into all my public methods, it's so repetitive.
Value types can't be null. You've had non-nullable types since 1.0.
Pingback from Algebaric Data Types again by ?? Tony’s blog ??
Pingback from Algebraic Data Types again by ?? Tony’s blog ??
i think you're just defining your function contracts wrong, and therefore assigning blame in the wrong place.
if i've got a function that takes an argument, and say calls a method on that argument, it's trivial, and almost implied, that you can't pass null into that function. whoever is passing null into that call is obviously in the wrong, and is probably doing so because they haven't finalized their code, and wanted to put a placeholder in so that it would compile (and perhaps forgot to take it out down the line). it's not that function's job to check if it was passed a null unless you explicitly define the function as being able to accept a null and doing something suitable (maybe silently ignoring the call).
if you're writing a public api and want to be all hand-holdy, perhaps you can add checks for your exported methods (but what could you do besides just throw an exception), but frankly i'd rather see the null pointer exception and backtrace when i actually execute the code. and i'd rather not have to deal with the compiler complaining because i'm writing some rough code that doesn't actually run yet, and i don't have the value yet.
i think this idea basically comes down to preventing a developer from doing something that they want to do "for their own good". that in no way sits well with me.
Please correct this blog to either not mention BigInteger or to say it has been removed. It's Internal in System.Core.dll from beta1 and forward and so it cannot be used by developers.
Done!
>Value types can't be null. You've had non-nullable types since 1.0.
Do you mean that we should get rid of all classes benefit (GC, inheritance...) and only rely on structure just to avoid the NullReferenceException?
> it's trivial, and almost implied that you can't pass null into that function
My opinion is that nothing is trivial with source code, especially infering some property from reading it. I want the property of my code to be obvious and checked automatically at compile-time.
>it's not that function's job to check if it was passed a null
I always apply defensive code: I don't know who calls me and always check and assert as many things as I can.
>what could you do besides just throw an exception
Get a compiler error that is much more cheaper
>but frankly i'd rather see the null pointer exception and backtrace when i actually execute the code. and i'd rather not have to deal with the compiler complaining because i'm writing some rough code that doesn't actually run yet, and i don't have the value yet
I think that a compiler error is always preferable than a runtime exception.
>>
My good old copies of mscorlib.dll v2.0.50727.0
<<
Don't you mean v2.0.50727.42 (or v2.0.50727.312 if you are on Vista)?
More detail here:
www.danielmoth.com/.../clr-v20-remains-at-same-version.html
BTW, a complete list of new stuff in 3.5 is here:
www.danielmoth.com/.../net-framework-35.html
Thanks Daniel, upadted!
"I expected to saw a new C:\WINDOWS\Microsoft.NET\Framework\v3.5.xxx folder"
The CLR is still 2.0 I knew that because I was looking for new machine.config and web.config files in the same location.
MS guys have a great and stable CLR 2.0 implementation in which they invested a lot. I completely agree with their decision to build the new stuff on top of this implementation.
However the 3.0 and 3.5 install still remains a bit dirty.
For another example, have a look in:
C:\WINDOWS\Microsoft.NET\Framework\v3.0
You have these folders:
{Windows Communication Foundation}
{Windows Workflow Foundation}
and while you would expect also a folder named
{Windows Presentation Foundation}
instead you found a folder named {WPF}?!
You might ask
'Who cares?'
and I would answer
'All ISV guys that build tools for .NET developers that need to reengineer the .NET installation' (as my company and many others)
I have to confess you created a wonderful UI for NDepend.
Cannot wait for the new version.
Wow Patrick, you've put a lot of thought into having the UI both ways.
I read this post with interest, caught by the title "UI matters"...I agree!
I also agree that MS must have put a lot of work into "Ribbons" and IMO "Ribbons" done properly have clear advantages over nameless 16x16 icons on a toolbar, and cascading menus several layers deep.
I'm only a casual user of NDepend, not very familiar with the product, but the difference in the 2 screenshots above is remarkable. You might have guessed that I favor the "Ribbon" approach. Just looking at the screenshots, it seems a lot less intimidating.
Good luck with your UI development,
Thomas
It looks great, but I wonder what happens if you select all three preferences (menu, toolbar and ribbon)...
Also, did you do that whole licence thing for the ribbon? Microsoft seems to think that because they put so much effort into the ribbon idea that you need a licence from them to use ribbons in your application. I don't know if that's really necessary, so I'm curious what you think about that.
Great, I'm glad that the facilities to choose between Toobars & Menus or Ribbon sounds not choking.
For Ribbon, there is a royalty-free license:
blogs.msdn.com/.../licensing-the-2007-microsoft-office-user-interface.aspx
If you select the 3 preferences, you'll simply have the 3 controls, which can look weird but DXperience allows this seamlessly so why not allowing it?
If you don't select any of the 3, the preference will go to the Ribbon.
I think you’ve made a great investment in improving the user interface. I’ve been evaluating NDepend for a short while, and the only thing that I felt was a bit quirky was the GUI. The core of NDepend is just like everyone describes it: awesome! I’m buying it in a few days. Keep up the good work!
By the way, I think you should have a look at the free NSIS and create an installation package using it. It features LZMA-compression (of 7-Zip fame), which shrinks your distribution quite a lot (you almost have to see it to believe it). And it’s fast and it won’t bloat your registry or anything.
If you for some reason don’t like NSIS, you could also check out Inno Setup. It’s free as well , and it also features LZMA-compression.
NSIS: nsis.sourceforge.net/Main_Page
7-Zip: http://www.7-zip.org/
Inno Setup: www.jrsoftware.org/isinfo.php
I dont own NDepend but have looked at the product several times. Just chompin at the bit to plop down my bucks when I have a few extra for tools instead of shoes for the kids.
I would definitely start with the ribbon interface and work myself to the toolbar as the ribbon would ge me off and running ASAP!
Just my two cents.
The trickiness of the ribbon UI in Office is that it supports all the Office 2003 menu commands (accelerators) like Alt+E,P for paste. I don't know what ribbon library your planning on using, but that sounds like a lot of work to support for those of us who have been using the "Common" windows menu keystrokes for 15 or so years.
But, I vote for keeping the option of menus or ribbons.
Pingback from entropia » Blog Archive » Removing vertical scrollbars when overflow is set to ‘auto’
Following on from my post on automated refactoring tools , I was going to talk a bit about how modern
The Ribbon looks nice, but I'm not sure if it's a good idea.
First, I'm not sure if you can ship it that way, because of the 'Office UI Guidelines' that you need to adhere if you use the Ribbon. They let you use it if you follow the guidelines, and I'm quite sure there should only be one Ribbon per application. That's the whole idea of the Ribbon, having one place where to find all the commands. In this case I think you should use the Contextual Tabs in the Ribbon to show both ribbons in one.
Second, I think you are just transferring your indecision to your users ;). If you want it to be easier for novices, add labels to the buttons and that will be probably enough.
Kind regards,
Andres
very good
Very good
I prefer the Ribbon UI. However as an aside, can you display the assembly info somewhere else besides the title bar? How about a yellow info bar (or something like that) at the top of the client area that displays this info?
We talked with the 'Microsoft Office 2007 UI design guys' and indeed we have to refactor the UI to abide by their rules, by adding an Application Menu, a QuickAccessToolbar and eventually grouping Ribbons.
It adds some work but I don't consider it as a burden as long as it will improve NDepend user experience. I'll blog more about this once it'll be done.
If we still propose menu & toolbars, it won't be a 'hot switch' but more likely a 'your changes will take effect the next time you lauch NDepend', for technical reasons.
Concerning the better cmpression algorithm, we unfortunatly cannot use something else than zip because it would force the user to download the others library.
>I think you are just transferring your indecision to your users ;)
Ribbon seems to be definitely a better choice than menu (most of comment goes this way). But the idea of being close to the VisualStudio UI Experience is also appealing, so it is hard to choice and indeed, you can see as transferring our indecision to our users.
This doesn't sounds as a bad thing to me however since it avoids disapointing anybody. If menu and toolbars in Office 2007 would have been an option, who would have used it?
If you read the posts about the new Office UI (blogs.msdn.com/.../the-office-2007-ui-bible.aspx, look for the posts on the Ribbon), the use was that there was a lot of commands that the Office users did not know about, and couldn't find. It does not look like your scenario.
Additionally, most NDepend users will probably be avanced users of Visual Studio, and won't need that much help. Looking similar to Visual Studio is definitely a good thing.
So, from an outsider point of view, I'd say that the Ribbon is overkill. Anyway, I know it looks cool and you already did it ;).
Thanks Andres for your remark.
Here is my point of you:
As said, NDepend's users are VisualStudio expert but at first they are also NDepend beginners. Ribbon are good to avoid burried commands but they are also great at making your buttons more verbose.
Anyway, if the user find the amount of screen real estate taken by Ribbon overkill, they still have the possibility to revert to VisualStudio mode at any time.
>Concerning the better cmpression algorithm, we unfortunatly cannot use something else than zip because it would force the user to download the others library.
I think you misunderstood me. What I tried to suggest was that you could almost effortlessly create a GUI-based setup---a single, easily downloadable, highly compressed EXE-file---using NSIS or Inno Setup. Once developed for WinAMP, NSIS is today used by many well-known software makers, and renowned for its configurability and ease of use (see nsis.sourceforge.net/Users). Inno Setup is equally well-established. Both are far from being as complex as Microsoft’s “enterprisy” Windows Installer (which also is very slow in comparison to NSIS/IS).
Indeed, I misunderstood you.
Thanks for the tip.
So, now that you have redesigned NDepend's GUI and know WPF, will NDepend 3 be in WPF?
We estimate that some part of the UI could gain from WPF feature. However, as you might know we already did a point on implementing tricky (and useful) effects (zoom, anim...) with GDI+ and that allow us to wait a bit.
Also, we must take account of the fact that the .NET framework 3 (or more) should be installed, which is not the case by now on most pro machine.
Finaly I'm a bit skeptical about WPF performance and wait about feedback. Using SetPixel()/GetPixel() WindowForms API takes 100 times more perf than playing directly with bitmap in unsafe mode, I hope that WPF has been more profiled than Windows Forms (on the other hand WPF is able to harness GPU perf...)
But it is definitely a good idea that we keep for the future.
The implication is that after installing Visual Studio 2008 on a machine, all new functions from V2.0.50727.1378 are available and may accidentally be used in Visual Studio 2005 projects. Everything works fine and is completely invisible for the developer, but a customer with V2.0.50727.42 gets a “Function not found” exception. This is strange and unexpected, because the developer uses Visual Studio 2005 explicitly to prevent this problem (as he uses Visual Studio 2003 earlier to create .NET 1.1 compatible applications).
I believe that most developers will not see the problem and maybe this situation lead us to new kind of DLL hell.
My post about our current work in enhancing the VisualNDepend UI with Ribbon Office 2007 style got a
So why exactly do you need to abide to a licence for a user interface? Did you have to do that for the old interface? If not, how is it an improvement for you and your product, that you need to have some licence for a GUI? Since when do we need a licence for the GUI we create. Did you get legal advice on this, or did they just scare you into it?
I don't know if asking this question violates some design heuristic of the ribbon control but from a screen real estate perspective is it possible to have the ribbon cascade in and out as needed? I would love this feature in Office 2007.
The Office 2007 Ribbon license doesn't cost a penny it is 100% free. My understanding is that MS created this license to make sure that in the future, all UI that uses Ribbon look alike. This way, it will be easier for users to get started with various products.
Our Ribbon experience relates this fact well. If you read my first post you'll see that our first UI choice were not that judicious and not very close to what Office UI looks like. If the license were not here to 'scare' us, maybe our UI would be more difficult to start with.
My opinion is that it is a good thing. Futue NDepend users that are used to Office Ribbon will feel at home when discovering NDepend. Also, MS spent hundreds of M$ in this Ribbon stuff, and I'm certain that me and my team could not have done a more comprehensive UI by ourselves.
Joe, I'm not sure to understand the term 'ribbon cascade in and out as needed' but if you mean having several Ribbon visible in the same Window the answer is no, the license doesn't permit that (maybe you can play with the 'Window' term, is a panel a window?). If you mean collapsing the Ribbon UI, take a look at Office 2007, it is already implemented by double-clicking any tab.
Awesome!!! I didn't know that, thanks Patrick! It's the simple things that make me happy.
The new UI looks great, and I'm a fan of the new Ribbon UI from MS. However, it was interesting to see that the DevX version does not strictly adhere to the guidelines. For the Quick Access Toolbar (QAT) the 9th guideline states that the right border MUST have a concave curve. They even go so far as to state the the radius of the concave curve MUST equal the radius of a circle centered in the app title bar.
A little too much guidance in my opinion - would rather have seen a SHOULD unstead of a MUST. But there you have it.
Keep up the good work. I'm mainly glad to see more people concerning themselves with user experience.
Pingback from Links (8/30/2007) « Steve Pietrek’s SharePoint Stuff
Pingback from UI matters: Menus and ToolBars vs. Office 2007 Ribbons - Patrick Smacchia [MVP C#]
We are glad that we have just released NDepend v2.4 with the thoroughly revamped UI that I talked about
Nice to see how to use NDepend and Reflector to locate a fix. Yes, wonderful demo for NDepend. This is a great post.
Gr8 post. How did you stop the exception when the stack trace contains the string
"System.Windows.Forms.ToolTip.CreateHandle()".
thx
Dama, this is a tricky thing not very well documented.
I'll certainly write a blog post to clarify things but basically you need to handle the event
System.Windows.Forms.Application.ThreadException += UnhandledExceptionOnUIThread;
...
private void UnhandledExceptionOnUIThread(object sender,
ThreadExceptionEventArgs e) {
// teh exception is reachable in e.Exception
// eventually show here you own errorForm dialog
if( mustAbort) {
m_MainForm.Close();
this will remove the WindowsForms default error dialog and let you a chance to swallow the exception / resume the program or abort ...
This is not obvious at all because the behavior is not the same when debugging your app.
Hope this help.
You know, this kind of thing is exactly why I don't use Microsoft technologies anymore.
Back in '97, I had two really nasty bugs in the same product, one on the Windows GUI, and one on the Linux GUI. The first one, we quickly traced down to MFC; the second, to Gtk.
It only took a day or two to find exactly what was wrong with both libraries. In both cases, there was no easy way to "hook" the code to fix it (Gtk is a C API; MFC is all C++, but the relevant function in CView wasn't virtual), and a workaround would have been a nasty mess in the MFC case, maybe not even possible in the Gtk case.
So, what did I do? First I submitted a bug report, along with a patch, to Microsoft, and likewise to the Gimp/Gtk/Gnome/XCF team.
The Microsoft bug was never closed; about two years later, VC6 came out with a new version of MFC without that bug, but even then our code had to be reworked to build on VC6 and use the new MFC42. In the meantime, we had to recode big chunks of CView and the subclasses we were using, wrap them up in an MFC extension DLL, add 40% to the total size of our install, and hold our release back for two weeks while legal verified that we were actually allowed to ship.
My Gtk patch was accepted almost immediately. It was in the main 1.0 tree within a few days, and in the Redhat packages within a few weeks. By the time we shipped, most of our customers probably already had it. (Just in case, we put RPMs, raw binaries, the diff, and complete sources on our site, but nobody downloaded any of them.)
Sure, the VC form designer was more polished than Glade, but in the end, the 3 minutes saved building dialog templates were not worth the huge costs of being tied to their libraries.
Today, I still write software for Windows, and for .NET. And I use their compilers. But I don't use WinForms unless I have to. With Gtk# or Qt#, I can fix problems myself, or get them fixed quickly, and my customers don't have to install an entirely new .NET runtime; just one DLL.
Hi Patrick,
What language will the speakers be using at this conference (I'm meaning German or English, not C# or VB ! :)
Cheers,
Steve
I tried it by moving 5 projects into 2. It maybe saves me 10% to 20%, no more, this includes the copy local setting. I have about 70.000 lines of C# code and it takes about 16 seconds to complete, on my AMD 3GHz notebook.
Visual Studio 2008 (beta 2) compiles in 13 seconds where 2005 takes 16 seconds :)
I'll talk english, my german is unfortunatly quite poor (I'm french).
Pingback from All Night Coder - Today’s Top Blog Posts on Programming - Powered by SocialRank
What prompted this? When would you ever need this?
Also you've lost ReSharper rename power. The IsDirectlyWritingField item takes a string, so if you change the name with ReSharper (or other tools) it will be disconnected. Also same problem with the type.
Do you get a compile-time warning/error if the attribute is disconnected from the property in any way?
You need this everytime you want to ensure a stronger encapsulation of a field.
A very common need for object encapsulation (not handled by the VisualStudio debugger), is to be able to track at debugging time all writing access to a field because you figured out that it ends up with an invalid state.
You can also imagine that you wish to do something each time you access the field, such as a transformation of the value or counting the number of access, or logging etc...
If the field get disconnected, the NDepend compiler cannot retrieve it and emit an error. So yes, you get warned if the field name get out of sync.
Without knowing a lot about NDepend and CQL, a neat feature might be to have the CQL constraint language be able to reference the attributed element.
So instead of having an attribute on m_Field and then again having to reference "m_Field" in the CQL, why not have something like:
"IsDirectlyWritingField ::referencedField"
That way you still retain renaming ability without sacrificing constraints.
Also, what is the reasoning for having something like CQLConstraint actually in the code? Maybe I'm a purist, but I hate to have things that aren't directly related to the functioning of the code cluttering up the visual flow of the code.
It seems that CQLConstraints would be better defined in an external file and run as a separate build step (like unit tests, FxCop, etc)
Your idea of
sounds good, we take note.
CQL queries and constraints can be written both in the code or in a separate NDepend project.
Personnally, I like to have CQL queries inside my code to make
the underlying intention explicit while reading at the code. I don't have to have the bodies of my method cluttered though, but this is not the case here.
I follow this easy rule of thumb: don't count them. And if it's required of me, I make up a reasonable number and begin looking for a new employer that is interested in code quality rather than meaningless metrics.
tim took my answer :[
I don't agree, LOC is far from being meanlingless.
Yes the LOC is not directly related to productivity ans should never be used as a yardstick.
However it is a the simpler way to coarsly measure the overall endeavour put in an application and to compare them. For example the codebase I am working on is 50K LOC while the .NET framework is around 500K LOC. Then, I have a pretty clear idea of the overall size of the framework.
Also LOC is useful when you have to plan some refactoring, or some migration because it will helps estimate the delay. If your team need a month to refactor X lines, it'll take around 2 months to refactor 2X LOC.
My previous post explained How to count the LOC of your .NET application and Tim B and Keith answered
On medium sized projects, we place the test in the same assembly and use NUnit's CategoryAttribute - which can be hooked into by NAnt or something.
First, thanks for following up Patrick. I'm used to being a blog lurker so it's a nice change to actively discuss a topic. With that said, your point is certainly not lost on me but it's been my experience that
A) if a metric is available, it will be used for planning and estimating regardless of its suitability for those purposes, and
B) no two applications (at least within the same company) are developed in the same context. They are written for different purposes and often by different developers, especially on large projects. I've read very little about project estimation so I may be misunderstanding this point.
If LOC analysis works well for a situation th