Anyone interested in giving Visual Studio 11 a temptative go, head over here and get it: http://www.microsoft.com/visualstudio/11/en-us/downloads
Happy Debugging!
Mittwoch, 29. Februar 2012
Donnerstag, 2. Februar 2012
WorkflowFoundation - Quickstart webcasts on MSDN
Whoever was happy enough to get the chance to implement a WorkflowFoundation-based solution knows the ultimate power that comes with the Framework.
If you haven't tried WF yet and are curious to try, you should do yourself the favour to watch the MSDN screencast series by Maurice de Beijer, located here. This is as good a round-up of the technology as I can imagine and deserves a great deal of attention.
I really can't imagine why those videos have so little views...
If you haven't tried WF yet and are curious to try, you should do yourself the favour to watch the MSDN screencast series by Maurice de Beijer, located here. This is as good a round-up of the technology as I can imagine and deserves a great deal of attention.
I really can't imagine why those videos have so little views...
Dienstag, 15. November 2011
A peek into the crystal ball - An empire named HTML5
After mobile Flash has been jilted, there's (more or less official) word out on the street that Silverlight 5 will be the last iteration of Microsoft's web interaction platform. Eventually, HTML5 seems to be the next big thing, and among many other reasons for the first major release of the web standard in ages, the following make most sense for me:
Microsoft sure knows how to amaze developers, and with the incarnation of XAML, have given us a toolset that enables us to develop for the web, the mobile and the windows platform in the same comprehensible way.
HTML5 is supposed to do the very same thing, and in addition enable us to develop for iOS and other non-.Net-aware platforms as well, all with the help of JavaScript (yuck!). That's what I call zombie technology : I thought JS was dead, but here it comes, stabbing us all in the back (or, from a more flowery perspective, giving us all the help we need).
Silverlight has - to my mind - always been one of those borderline technologies : I was never really certain whether it was a proof of concept (we can do what flash can do, but better) or a great white hope (with financial profit for Microsoft). The EOL notice - be it official or not - will give Silverlight 5 developers, authors and trainers a very hard time finding business, and what remains will be the technology that benefits from the Silverlight mindset (WPF, WP7), at least until it falls over the saucer's edge as well.
In the end there will be one major Client technology, and that will be HTML5. That, of course, will only be true until its insufficiencies in specific scenarios show up and the next more colorful fish swims along. Even nowadays there's Delphi software being used and maintained, I have even come across a few COBOL relics in productive use. As technology lifecycles become shorter, it is us developers who have to keep up with the pace, which means : If you're a WPF specialist today, you should aim at becoming a WinRT specialist tomorrow. The environment is changing faster than ever, and yes - even HTML5 will be old in a few years' time. The empire rises and falls.
A question to ponder about : How do I ever become a seasoned expert, how can I distinguish from the masses when the environment crumbles and rebuilds in shorter cycles? Any ideas? Mail me, I'd love to read those!
- No Framework or runtime required
- open specification
- in future, every browser will implement it without a plugin (bringing an end to license hell)
Microsoft sure knows how to amaze developers, and with the incarnation of XAML, have given us a toolset that enables us to develop for the web, the mobile and the windows platform in the same comprehensible way.
HTML5 is supposed to do the very same thing, and in addition enable us to develop for iOS and other non-.Net-aware platforms as well, all with the help of JavaScript (yuck!). That's what I call zombie technology : I thought JS was dead, but here it comes, stabbing us all in the back (or, from a more flowery perspective, giving us all the help we need).
Silverlight has - to my mind - always been one of those borderline technologies : I was never really certain whether it was a proof of concept (we can do what flash can do, but better) or a great white hope (with financial profit for Microsoft). The EOL notice - be it official or not - will give Silverlight 5 developers, authors and trainers a very hard time finding business, and what remains will be the technology that benefits from the Silverlight mindset (WPF, WP7), at least until it falls over the saucer's edge as well.
In the end there will be one major Client technology, and that will be HTML5. That, of course, will only be true until its insufficiencies in specific scenarios show up and the next more colorful fish swims along. Even nowadays there's Delphi software being used and maintained, I have even come across a few COBOL relics in productive use. As technology lifecycles become shorter, it is us developers who have to keep up with the pace, which means : If you're a WPF specialist today, you should aim at becoming a WinRT specialist tomorrow. The environment is changing faster than ever, and yes - even HTML5 will be old in a few years' time. The empire rises and falls.
A question to ponder about : How do I ever become a seasoned expert, how can I distinguish from the masses when the environment crumbles and rebuilds in shorter cycles? Any ideas? Mail me, I'd love to read those!
Dienstag, 30. August 2011
Something very much like a PropertyGrid!
I've been working on a WPF Toolkit for my pastime project CrystalWars tonight, when I stumbled upon this lovely implementation of a PropertyGrid in WPF.
At first sight, and working with basic data types only, it works very smoothly. I'll have to dive into the custom section in the next fewdays nights. The tutorial looks pretty telling to me.
At first sight, and working with basic data types only, it works very smoothly. I'll have to dive into the custom section in the next few
Donnerstag, 14. April 2011
Getting the Crisp back into your WPF Apps
WPF has a lot of advantages, it's perfectly sane data binding mechanism being one of the most outstanding ones.On the flipside, many people (meaning companies, mostly) have refused to switch from WinForms to WPF because of the "blurry" looks of applications written in WPF.
This blurryness goes back to two mechanisms:
1)Text Smoothing
Instead of relying on the system's ClearType mechanism, WPF does it's own thing-a-magic, which is blatantly inferior to the aforesaid. In fact, WPF smoothed fonts are a definite way to headaches, if read for some time.
Note : The image is from a website that compares various Microsoft.Net Font-Smoothing implementations.
They might be useful to integrate text in images, though.For business applications (displaying data grids etc.) this is a K.O. criterion. Nobody wants to have to take their glasses off in order to achieve readability, and nobody wants their software deployed along with a pack of aspirins.
2)SubPixel positioning
Based on the fact that the WPF Engine positions Elements not only on pixel positions but also somewhere between them, it has to calculate values for the neighboring pixels in order to display graphical objects (controls, images,...).
In that respect, WPF is a little over-achiever! The result is a pixel with a color value based on those of two or four surrounding pixels, visibly as crisp as a drop of ink in a water jar.
What we initially hoped to be a cure, turned out to be ineffective : The SnapsToDevicePixels Property. I have tried adding it to all hierarchies of the visual stack, but without any trace of success.
By default, WPF uses what it can to achieve a smooth look, so those mechanisms are set to work by default. For years, Microsoft has either ignored or not been able to satisfy the community's yell for help. Finally, with the release of WPF4, the options to switch those mechanisms off, are here!
Here's two steps to get your crispiness back :
1) TextFormattingMode
To get rid of WPF Not-So-ClearType font rendering, your root element should set the property TextOptions.TextFormattingMode to "Display". This, like Renderoptions.BitmapScalingMode, is an attached Property and can be set on a per-control level as well.
2) UseLayoutRounding
Using Layout rounding solves all issues based on SubPixel positioning, as it moves the elements to pixel positions instead.
That being said, it does what we would have expected SnapsToDevicePixels to do. As far as I have tested, all declarations of SnapsToDevicePixels can now safely be removed.
Fortunately, it has to be declared at top level, so
Further details on Layout Rounding can be read here .
If your Images are scaled rather than used in their "native size", you might want to set the BitmapScalingMode property of your Top-Level declaration (e.g. Window or Page) to utilize HighQuality rendering.
That should cease the era of the WPF-headache! All hail to King Crispy!
This blurryness goes back to two mechanisms:
1)Text Smoothing
Instead of relying on the system's ClearType mechanism, WPF does it's own thing-a-magic, which is blatantly inferior to the aforesaid. In fact, WPF smoothed fonts are a definite way to headaches, if read for some time.
Note : The image is from a website that compares various Microsoft.Net Font-Smoothing implementations.
They might be useful to integrate text in images, though.For business applications (displaying data grids etc.) this is a K.O. criterion. Nobody wants to have to take their glasses off in order to achieve readability, and nobody wants their software deployed along with a pack of aspirins.
2)SubPixel positioning
Based on the fact that the WPF Engine positions Elements not only on pixel positions but also somewhere between them, it has to calculate values for the neighboring pixels in order to display graphical objects (controls, images,...).
In that respect, WPF is a little over-achiever! The result is a pixel with a color value based on those of two or four surrounding pixels, visibly as crisp as a drop of ink in a water jar.
What we initially hoped to be a cure, turned out to be ineffective : The SnapsToDevicePixels Property. I have tried adding it to all hierarchies of the visual stack, but without any trace of success.
By default, WPF uses what it can to achieve a smooth look, so those mechanisms are set to work by default. For years, Microsoft has either ignored or not been able to satisfy the community's yell for help. Finally, with the release of WPF4, the options to switch those mechanisms off, are here!
Here's two steps to get your crispiness back :
1) TextFormattingMode
To get rid of WPF Not-So-ClearType font rendering, your root element should set the property TextOptions.TextFormattingMode to "Display". This, like Renderoptions.BitmapScalingMode, is an attached Property and can be set on a per-control level as well.
2) UseLayoutRounding
Using Layout rounding solves all issues based on SubPixel positioning, as it moves the elements to pixel positions instead.
That being said, it does what we would have expected SnapsToDevicePixels to do. As far as I have tested, all declarations of SnapsToDevicePixels can now safely be removed.
Fortunately, it has to be declared at top level, so
Further details on Layout Rounding can be read here .
If your Images are scaled rather than used in their "native size", you might want to set the BitmapScalingMode property of your Top-Level declaration (e.g. Window or Page) to utilize HighQuality rendering.
That should cease the era of the WPF-headache! All hail to King Crispy!
Freitag, 8. April 2011
Deploying ClickOnce-applications in different environments without modifying the assembly identity
The following describes a method that is viable for ClickOnce deployment using "Online Only" mode.
One of the aspects I recently pondered about is code identity. In other words : Auditors ask me how I ensure that the software tested and accepted by the departments is exactly and with no alternations the assembly we deploy for productive use and not some tinkered-with version.
"That's easy", I say, "I can't!". Because some config-variables are set between approval and release, the ClickOnce hashes differ and thus does the whole thing.
The image depicts the requirement rather roughly, but I think more detail is not required: An application should be stateless and not compiled to fit it's environment.
The first thing coming to my mind to sail around this kind of trouble is keeping the App.config (or any other file of my personal gusto) a part of the deployment, but removing it from the hash. That would be easy, fast and a little dirty.
First and foremost, and that should suffice as a counter argument, it would annihilate the ability to sign the ClickOnce manifest, which is really a nuisance. Not being able to add an issuer certificate would result in user frustration, as they would have to confirm their trust in me every time I publish an update of the software.
After some research I tried using the ApplicationDeployment class, and here's a snippet I created that does the job:
One of the aspects I recently pondered about is code identity. In other words : Auditors ask me how I ensure that the software tested and accepted by the departments is exactly and with no alternations the assembly we deploy for productive use and not some tinkered-with version.
"That's easy", I say, "I can't!". Because some config-variables are set between approval and release, the ClickOnce hashes differ and thus does the whole thing.
The image depicts the requirement rather roughly, but I think more detail is not required: An application should be stateless and not compiled to fit it's environment.
The first thing coming to my mind to sail around this kind of trouble is keeping the App.config (or any other file of my personal gusto) a part of the deployment, but removing it from the hash. That would be easy, fast and a little dirty.
First and foremost, and that should suffice as a counter argument, it would annihilate the ability to sign the ClickOnce manifest, which is really a nuisance. Not being able to add an issuer certificate would result in user frustration, as they would have to confirm their trust in me every time I publish an update of the software.
After some research I tried using the ApplicationDeployment class, and here's a snippet I created that does the job:
private static void GetDeploymentEnvironment()
{
if (ApplicationDeployment.IsNetworkDeployed)
{
ApplicationDeployment dep = ApplicationDeployment.CurrentDeployment;
FileInfo f = new FileInfo(dep.UpdateLocation.AbsolutePath + ".env");
if (f.Exists)
{
/// read file content and apply settings
}
}
}
Donnerstag, 7. Januar 2010
Duplicate items are not supported by the "Resources" parameter
This is an Error Message that I have encountered for the first time today.
It is most likely to occur when you copy forms and rename the copy automatically,
which will cause the original to be renamed, too.
In my first project I split the code of a Form into many partial classes, one partial class for each
tab in the form. I created new partial classes the copy & paste way, which worked alright before, but
today I got the Message
The item [...].resources was specified more than once in the "Resources" parameter.
Duplicate items are not supported by the "Resources" parameter
Actually you can only have one Resources File per class. What I did was unknowingly copy the form including the resources file
(...that the VS project explorer hides under the Form's node), so that the resources were double-linked.
Solution: delete the second resource file.
BTW: As of now, I will also try to make my posts googleable for developers with a german IDE by
adding German search terms or error messages:
Das [...].resources-Element wurde im Resources-Parameter mehrfach angegeben.
Doppelte Elemente werden vom Resources-Parameter nicht unterstützt.
It is most likely to occur when you copy forms and rename the copy automatically,
which will cause the original to be renamed, too.
In my first project I split the code of a Form into many partial classes, one partial class for each
tab in the form. I created new partial classes the copy & paste way, which worked alright before, but
today I got the Message
The item [...].resources was specified more than once in the "Resources" parameter.
Duplicate items are not supported by the "Resources" parameter
Actually you can only have one Resources File per class. What I did was unknowingly copy the form including the resources file
(...that the VS project explorer hides under the Form's node), so that the resources were double-linked.
Solution: delete the second resource file.
BTW: As of now, I will also try to make my posts googleable for developers with a german IDE by
adding German search terms or error messages:
Das [...].resources-Element wurde im Resources-Parameter mehrfach angegeben.
Doppelte Elemente werden vom Resources-Parameter nicht unterstützt.
Abonnieren
Posts (Atom)