rwandering.net
The blogged wandering of Robert W. Anderson
January 9, 2009 at 9:07 am · Filed under .NET, Miscellaneous
A couple of years ago, I wrote Three deficiencies in the C# preprocessor. Those issues still exist, but a good thing about C# is you don’t get the following problem . . .
I’m working on a project for a customer that includes upgrading a VC++ 6.0 DLL to VC++ 2008. There are some good resources on MSDN for breaking changes (for a starting point, see http://msdn.microsoft.com/en-us/library/bb531344.aspx). Of course, I didn’t start there, I started by just trying it. Pretty quickly I came across some of the breaking changes related to STL (specifically that iterators cannot be treated as pointers).
But I also had a pretty bewildering problem. Hundreds of the following errors:
error C2371: 'std::tr1::placeholders::ks' : redefinition; different basic types
The source of the error was C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xxbind1, line 298. Looking there, I found:
// PLACEHOLDER ARGUMENTS
namespace placeholders { // placeholders
static _Ph<_NARGS> _CLASS_NAME(_);
} // namespace placeholders
Doing some investigation I found that xxbind1 is related to the TR1 extensions to the Standard Library. The errors didn’t help me figure out where my code was including this file, so using the process of elimination (and the trusty binary search), I found that excluding the STL map header (i.e., <map>) solved this problem. Not an option, though, since the code in question relies on stl::map.
So, I tried several other avenues to figure out what I was doing wrong. While scouring all the application header files leading up to this include, I found the following line:
#define _ ks._
I thought, “wow, that looks awfully general for a preprocessor constant in the main internal header file”. Going back to the code in xxbind1, now that error makes sense.
Removed it, and everything is fine.
Arbitrary string-replacement before compilation is a powerful thing, but it can allow seemingly unrelated and unintended havoc.
Tags: .NET, c#, VS2008
February 20, 2008 at 6:39 pm · Filed under .NET, Grid Computing
Last week, PowerShell Architect Jeffrey Snover wrote an excellent post titled the Semantic Gap. He writes about the gap as . . .
. . . 2 worlds:
- The world as we think about it.
- The world as we can manipulate it.
The difference between these two is what is called the semantic gap.
This is a great working definition.
Jeff writes about this specifically regarding PowerShell and instrumentation providers and asks the question,
So why do instrumentation providers close or not close the semantic gap?
Yes, some do, and some don’t. This isn’t just about hierarchy of needs, but also about prioritization. How important to the provider is a narrow semantic gap for product X when used through interface Y?
In the case of X := Digipede Network and Y:= PowerShell, we thought it pretty important.
But how do you decide if narrowing the gap is worth it? Engineering costs aside, understanding what your interface could look like in PowerShell can help you decide. Internally, we answered these questions:
- What would a PowerShell script look like just using your .NET or COM APIs?
- What could it look like with Cmdlets?
- Would these Cmdlets support how we think about the Digipede Network (i.e., small gap?).
I already said the answer to #3 turned out to be yes and in a previous post, I gave an example of the gap in Why a SnapIn for the Command-Line? This example highlights the gap for a common operation on the Digipede Network: get the description of a pool of resources.
If you are thinking about supporting PowerShell in your product, take a look at my post.
I hope this helps you decide.
[tags]NET, c#, Cmdlet, Digipede, PowerShell[/tags]
Tags: .NET, c#, Cmdlet, Digipede, PowerShell
October 26, 2007 at 5:43 am · Filed under .NET, Grid Computing
On Tuesday I posted about the new Digipede SnapIn for PowerShell.
One question I didn’t get into is, why write a SnapIn when PowerShell supports full scripting for .NET APIs? The short answer is that we can provide a better command-line experience with PowerShell cmdlets than the “out of the box” PowerShell experience. Windows PowerShell Architect, Jeffrey Snover, did a great post on this a few months back: Cmdlets vs. APIs.
I thought I’d give an example of the difference as it relates to the new Digipede SnapIn.
For example, suppose you want to enumerate the pools on a Digipede Network. Natively in PowerShell, you can do the following:
[System.Reflection.Assembly]::LoadFrom("C:\\Program Files\\Digipede" +
"\\Framework SDK\\v2.0\\Net2.0\\Digipede.Framework.dll")
$DigipedeClient = New-Object -TypeName Digipede.Framework.Api.DigipedeClient
$DigipedeClient.SetUrlFromHost("MYSERVER")
$DigipedeClient.Management.GetPools() | ft
That is pretty verbose (note the first line is split in two to improve readability in my blog). This same operation becomes much simpler with the Digipede SnapIn:
Add-PSSnapIn DigipedeSnapIn
$DigipedeClient = New-DNClient -Network MYSERVER
Get-DNPool
And what about the output? Without any extra information, PowerShell will format output on its own — a very cool feature. The former example produces a default table output:
IsReadO PoolId Name Descrip Collect Schedul Potenti TotalCo JobTota TaskTot
nly tion ion ingAlgo alGhz mputeRe lComple alCompl
rithm sources ted eted
------- ------ ---- ------- ------- ------- ------- ------- ------- -------
True 1 Mast... Mast... {Mas... ...rity 66 19 665 57584
True 601 Fifo {Mas... ...tOut 18 3 0 0
PowerShell can’t determine which properties should be included, so it makes a guess. The DigipedeSnapIn includes formatting information to give much more readable (and useful) default output:
PoolId Name Description Resources Potential
GHzH
------ ---- ----------- --------- ---------
1 Master Pool Master Pool 19 66
601 Fifo 3 18
So, the SnapIn definitely provides a better command-line experience. And the great thing? These two worlds are not mutually exclusive. For example, suppose you want to specify the default pool for a DigipedeClient object? We haven’t exposed that as a property on New-DNClient nor provided a cmdlet for this purpose, but the API includes the PoolId property. Just do this:
$DigipedeClient.PoolId = (Get-DNPool -Name "Fifo").PoolId
Now, the default pool is a pool named “FIFO”.
This brings me back to something I wrote in my previous post: PowerShell is cool.
[tags]Digipede, .NET, PowerShell, Cmdlet, C#[/tags]
Tags: .NET, c#, Cmdlet, Digipede, PowerShell
October 25, 2007 at 6:25 am · Filed under .NET, Grid Computing
I’ve been playing with LINQ here at Digipede for various reasons, one of which is to put together a sample for using LINQ on top of the Digipede APIs. I haven’t gotten together any code to post (primarily because I’ve been pushing on our PowerShell SnapIn in my “spare” time).
A pleasant surprise this morning: Matt Davey posted a code sample on his blog: GridLINQ and Digipede.
I knew he was working on something. Yesterday, Nathan helped Matt with some installation issues (kudos to Nathan and thanks to Matt for the assist). Anyway, at some point Nathan says to me:
You know, Rob, you should connect with Matt on IM. He tells me he tried LINQ with the Digipede Network and “it just worked”. He’s IM’ing me about it and I’ve never even seen a line of LINQ code!
Thanks for the posting, Matt. Keep up the posts and we’ll put you up for Digipede MVP!
BTW: It looks like Matt’s sample will run on either Digipede Network 1.3 or 2.0 — I want to point out, though, that Digipede Framework collections only started supporting IEnumerable<T> directly in version 2.0; so v2.0 is more LINQ friendly.
[tags]Digipede, .NET, LINQ, C#, Grid[/tags]
Tags: .NET, c#, Digipede, grid, linq
October 23, 2007 at 11:34 am · Filed under .NET, Grid Computing
Today we posted a preview of our PowerShell SnapIn for the Digipede Network — go to the Digipede community site for details and download instructions.
This preview provides a functioning command-line interface to much of the available Digipede Network management APIs. This functionality will continue to be enhanced along with the underlying APIs (more on this in a future post).
This preview is a little bit of a departure for us at Digipede. While we have targeted previews to customers in the past, this is the first time we have made one publicly available. A bigger departure, though, is that we are also including full source code to this preview.
Digipede is not open-source, so why release the SnapIn code?
- The SnapIn provides excellent examples for the Digipede Management APIs. The SnapIn is also a good example of a PowerShell SnapIn.
- By providing a sample as a SnapIn we are reducing the startup costs for our customers to develop their own cmdlets (for the Digipede Network and otherwise).
- We hope that some community members will provide feedback in the form of suggestions, fixes and maybe even new cmdlets — this will help make the SnapIn better faster.
Another question might be, why do a PowerShell SnapIn at all? After all, PowerShell does a great job with .NET APIs without any additional support.
- PowerShell does do an excellent job with .NET APIs (and COM APIs too, for that matter). But this support is better suited to scripting than to a great command-line interface. I will post an example of this difference later this week.
- For some customers, a command-line interface is important. PowerShell provides a standard framework into which such interfaces can be built — the days of writing one’s own custom command-line interfaces are thankfully past.
- PowerShell is really cool.
If you are interested in PowerShell, the Digipede API, or a command-line interface to the Digipede Network, please take the time to try out the preview. We would love to get feedback from you on what else it needs, any problems you find, and ideas for other cmdlets — implementations even better!
To learn more about Windows PowerShell, visit the Microsoft Windows PowerShell home page as well as the PowerShell Team blog.
[tags]Digipede, .NET, PowerShell, Cmdlet, C#[/tags]
Tags: .NET, c#, Cmdlet, Digipede, PowerShell
August 27, 2007 at 10:48 am · Filed under .NET
Back in March, I posted Automatic Properties in C# 3.0 which included a couple of questions. At the time I hadn’t installed any Orcas beta. My post was based on other posts (including one from Bart DeSmet’s excellent blog: C# 3.0 Automatic Properties Explained). My questions leapt out at me (maybe I’ll post about why that is . . .). Since that post, I have played a bit with the VS 2008 betas as well as built and tested the Digipede SDK samples.
A recent comment reminded me that I should revisit the questions.
Question 1: Is there an attribute to set the automatic field name?
Reason? To maintain binary-serialization compatibility when moving from automatic properties to “normal” properties.
Answer: I don’t know if there is explicitly. The underlying field name seems to have been changed since Bart’s first post and VS 2008 beta 2 (they have improved it so the field name can be derived from the property name). This is good, because it might mean that the automatic property could be converted to the “normal” kind of property while maintaining default binary serialization; however, the backing field name looks like:
<PropertyName>k_BackingField.
. . . and angle brackets are not valid for member names — the compiler can generate them, but aren’t valid C# syntax. So, this is not quite what I want.
Question 2: Is there an attribute you can put on the automatic property to hide the underlying field or is it automatic?
Reason? By default, properties with backing fields result in (usually) duplicated information in the debugging views. If the backing field is generated by the compiler, it would make sense to just hide it (with the DebuggerBrowsableAttribute or some other way).
Answer: This is automatic. Good. Probably a result of the CompilerGeneratedAttribute that is added to the generated backing field.
Summary
Based on what I know now, I wouldn’t use automatic properties if default binary serialization is likely to be used. Regardless of this possibly arcane issue, automatic properties are cool. I like them.
[tags]Digipede, C#, C#3.0, .NET, .NET3.5[/tags]
Tags: .NET, .NET3.5, c#, C#3.0, Digipede
August 8, 2007 at 4:03 pm · Filed under .NET
Can someone explain why the following expression evaluates to true? There must be some historical perspective that I’m just missing.
new Uri("mailto:somebody@example.com") == new Uri("mailto:somebodyelse@example.com")
I would understand:
- A use case for a separate Uri.Compare method giving the caller control over which components should be compared;
- If Uri.Equals performed its comparison against canonicalized URIs.
The docs say that the user info, fragment, and (in older .NETs) query are all ignored for comparison. There is no mention for the email address in a mailto; however.
What? Why?
[tags].NET, C#, Microsoft, BCL[/tags]
Tags: .NET, BCL, c#, Microsoft
December 18, 2006 at 8:51 am · Filed under .NET
Jamie Cansdale, author of the excellent TestDriven.net, has organized several charity auctions to help people in Malawi. In his words:
I have decided to organize a charity auction of a number of licenses for .NET developer tools. All proceeds of the auction will be given to Wells for Zoë, a charity dedicated to increasing the availability of safe drinking water and water for irrigation in rural areas of Malawi. You can read more about the project on their website or blog.
One unusual thing about this charity is that all travel and admin expenses are paid by the charity’s founders themselves. Therefore all donations go directly to sourcing the much needed equipment on the ground in Malawi. You can find out more about the equipment that is needed on the donation page here.
The software is being auctioned on eBay (they complete at the crack of dawn Pacific Standard Time on Wednesday):
If you want any of these excellent products, bid away!
[tags]Testdriven.NET, MSDN, SourceGear, TypeMock, CodeRush, DXperience, MegaPack.Net, Thycotic, C#, .NET, .NET3.0, VS2005[/tags]
Tags: .NET, .NET3.0, c#, CodeRush, DXperience, MegaPack.Net, MSDN, SourceGear, TestDriven.NET, Thycotic, TypeMock, vs2005
May 11, 2006 at 7:22 am · Filed under .NET
C# 2 has anonymous delegates. I like them. Of course, they enable advanced constructs like closures and continuations, but one of I’m a pushover for language and environment features that improve readability and maintainability of code. Before C# 2, if you wanted to perform a task on another thread, you might do something like this:
/// Do something worker callback
private void DoSomethingImpl(object callerData) {
// implementation here
. . .
}
/// Do something on a threadpool thread
private void DoSomething() {
// invoke on threadpool thread
ThreadPool.QueueUserWorkItem(new WaitCallback(DemoJob));
}
With anonymous delegates, you can just do this:
/// Do something on a threadpool thread
private void DoSomething() {
// invoke on threadpool thread
ThreadPool.QueueUserWorkItem(delegate(object o) {
// implementation here
. . .
}) ;
}
Fewer lines of code. Easier to maintain. Logic easier to follow. The pattern gets even nicer when your worker method needs arguments. For example:
/// Do something on a threadpool thread
private void DoSomething(int a, double b, SomeClass c) {
// invoke on threadpool thread
ThreadPool.QueueUserWorkItem(delegate(object o) {
// implementation here can use a, b, and c
. . .
}) ;
}
To pass the three arguments a, b, and c to a named method would require a custom class or packaging in a collection or array. I won’t show you how to do it. It is tedious, after all.
Tags: .NET, c#
April 20, 2006 at 6:45 am · Filed under .NET
I’ve started reading Practical .NET2 and C#2 with the intention of reviewing it. Even though the book is intended for beginner to intermediate programmers, I’ve already learned some things I missed while porting to .NET 2.0. When my review is done, I’ll post it as a new article.
It is written by Patrick Smacchia, author of the excellent NDepend. If you haven’t used that, go and check it out. Once our code is all Code Anaylsis-clean, I’ll probably play with using its Code-Query-Language (CQL) to enforce other standards.
Note to Patrick: I would have called it ILQL for Intermediate-Language Query Language (pronounced ill-quill) since CQL is presumably prounounced sequel. My guess is that this pronunciation match was intentional (and it is kind of cute), but in describing it to others I’ve had to call it by other names so I don’t confuse them (e.g., “not-SQL” and “code query language”).
Tags: .NET, c#, CQL, NDepend
Next entries »
About me
Main feed
Email subscriptions