rwandering.net
The blogged wandering of Robert W. Anderson
February 7, 2008 at 11:11 am · Filed under .NET
Of course there is APL (A Programming Language), B (boiled down from BCPL), C et al., and T (a dialect of Scheme which is a dialect of Lisp).
And, while there are several languages called ‘D’, Microsoft seems to be building a new one. At least it has the code name ‘D’. This is apparently not the same as the “D Programming Language”, but appears to be a declarative language relying heavily on XML (or XAML).
Please Microsoft, if you are going to stick with the letter ‘D’, disambiguate it. Call it
- D#; or
- Visual-D; or
- D.NET; or
- DEE; or
- MSD; or
- something else. I hope this last one is the leading contender.
But whatever you do, make it searchable. The only thing making it easy to find useful information about .NET on the Web is that most .NET bloggers use C#. C# is searchable. .NET is not. Nor, by the way, was COM (and I hope you aren’t getting any ideas about using the word ORG or MIL for new technology names).
So, Microsoft and .NET community, please join in me in the refrain:
A, B, C, T, please don’t call your language D,
E, F, G, H, I, J, disambiguate.
All Together Now.
Apologies for the extra syllable.
[tags]Microsoft, .NET, D, D.NET, XAML[/tags]
Tags: .NET, D, D.NET, Microsoft, XAML
February 5, 2008 at 10:02 am · Filed under .NET
Last week I posted on some things I like about VS2008. Here are some things that I don’t particularly like, or at least things that I wish had been updated. Consider these feature requests for VS.NEXT (or TFS power toys) or a service pack.
- First of all, a bug. It has a habit of closing itself. I’m usually in the middle of a build when this happens. It just goes “poof”. Sometimes more than once a day. Sometimes it does not repeat for days.
The rest of these are really just suggestions. The Visual Studio Team will probably just roll their eyes and say “yeah, we know” or “why didn’t you suggest this before?” Yeah. Better late than never?
- While targeting older versions of .NET 2.0 is great, I wish there was read-only support for VS2005 projects without conversion. The driver for down-level support must have been to remove barriers-to-sale for existing VS2005 customers, but read-only support would have been better. Why?
- So teams with a lot of projects can “convert as they go” and not need to do a wholesale conversion of everything.
- To make it easier to maintain older versions of their product without having to keep VS2005 around.
- The source control diff tool needs to be updated. My major annoyances?
- It doesn’t use the same keyboard shortcuts as Visual Studio (or Office for that matter). Alt-F3 for Find?
- It can’t be minimized. It can be resized, but why not minimized?
- I would love to be able to diff with horizontal panes. Since the code is so often wider than the pane, I have to scroll around. This slows down changeset code audits.
- While I love the Excel view of TFS work items, we still cannot edit the entire item from Excel. I really hoped this would have been added.
- And on the subject of TFS, there should be a quick find feature built into the IDE. Writing a query to do a find is too many steps. We shouldn’t have to rely on outside tools for this (e.g., TFS Quick Search which hasn’t been updated yet).
Will there be more? Certainly. I haven’t spent much time with the new features of the IDE. But I’m sure there will be a lot more that I like too — I’m very happy to be using the new IDE.
[tags].NET, Microsoft, TFS, VS2008[/tags]
Tags: .NET, Microsoft, TFS, VS2008
January 28, 2008 at 6:18 pm · Filed under .NET
Leaving out all .NET enhancements, here are a few things I like about VS2008:
- Down-level .NET support. This makes the upgrade much easier for those of us who still support older versions of Windows that don’t support the new versions of .NET. I wish they had gone a step further — I’ll write that up in a companion post.
- Doesn’t require elevation. I recently started using UAC again (i.e., I turned it back on) and found it annoying that I couldn’t drop files into VS2005 (since it runs elevated and Explorer does not). It is important that VS2008 works unelevated, because UAC is important. If you make it too hard for devs to use UAC, they’ll turn it off. And as I know from personal experience, they won’t be as motivated to support it.
- Supports application manifest files as a project property (instead of through custom post-build steps). We just implemented this manually for the “Certified for Server 2008 Logo” and I was very happy to eliminate that in favor of direct tool support.
- It seems to start about 100 times faster than VS2005. I’m not kidding.
- The Source Control “Annotate” feature — glad it got rolled into the release. I like the fact that it is available directly from the history menu, making it much easier to find when some line of code was introduced.
Just a few things. I’m sure I’ll find more soon.
[tags]microsoft, vs2008, .NET, TFS[/tags]
Tags: .NET, Microsoft, TFS, VS2008
January 10, 2008 at 11:00 am · Filed under .NET
This is a community service post. When I come across a problem and I can’t find a solution to it on the Internet, I try to put a solution into the public record. This one is obscure.
When running ilasm I got an exit code of -1073741819 (the fairly generic C0000005 code). The problem turned out to be due to an incompatible PDB file in the same directory as the input files. I experienced this running ilasm for .NET 1.1 with a pre-existing .NET 2.0 PDB file from a previous step in our build process.
To be clear: the PDB file that caused the problem had the same base name as the IL being read and assembly being generated. It appears that ilasm reads the PDB if it already exists, but since the file is incompatible it returns an error.
The solution here was easy: just delete or move the offending PDB.
Note that if you are running ilasm indirectly through the PreEmptive Dotfuscator product, you will see an error like this:
ilasm returned -1073741819
The FAQ at PreEmptive says that this is due to a problem of path depth (i.e., running ilasm too deeply nested in folders). That may sometimes be the case too. I don’t know.
Tags: .NET, .NET1.1, Dotrfuscator, ILASM, PreEmptive
November 17, 2007 at 6:33 pm · Filed under .NET, Grid Computing, Web 2.0
John has an excellent post wrapping up his trip to SC ‘07 — the bashers’ ball. He is tired of all the Microsoft bashing:
It is amazing to me the level of religious fervor that Microsoft still inspires. The bashers out there can be perfectly calm and reasonable about a wide range of topics – but say the word “Microsoft,” and they turn bright red and irrational. I have watched this phenomenon for years, and still find it inexplicable. Microsoft is a company. That company makes software. Some of their software is very, very good. Some of it is remarkably bad. I don’t understand why some people find it so hard to remain objective (or even civil) when discussing their products and market presence.
Statement of fact. Nothing new exactly, but then he goes on how this relates to our company (emphasis mine) . . .
Many Microsoft bashers think that all of us at Digipede are mouthpieces for the Evil Empire, and that we are just pawns of the Microsoft machine. On the other hand, while we have plenty of fans within Microsoft, there are also some Microsoft employees who think we are difficult annoying troublemakers . . .
Pawns of Microsoft? Please. But maybe we are misunderstood. The other day I found myself convincing Steve Gillmor that I’m not a Microsoft fanboy (I don’t think I succeeded). But John says it well,
In fact, none of us at Digipede love or hate Microsoft – we work with Microsoft. We do so for real-world business reasons that help us change the world for the better while building a great company. We work with other companies too, but Microsoft occupies a special place in the technology landscape, and we work very, very hard to understand how to work with them to our mutual benefit. There are some great people there doing great things, and the bashers only hurt themselves by blinding themselves to these very real contributions.
Yeah, I don’t love or hate Microsoft; however, I do really like Microsoft .NET. Does that make me a pawn of Microsoft? .NET isn’t my religion. I’m not a zealot about it. It doesn’t mean that I think everyone should be using .NET / Windows nor does it require that I go around bashing Apple / Sun / IBM / Google / Linux / Java / PHP / Rails / whatever.
I don’t think Microsoft bashing is a requirement for entry to the HPC and Apple fan clubs either, is it?
As long as I can remember, I have detested the religion of the OS (or programming language, or platform, etc.). Passion for technology is great — it’s a requirement for success in this field. But I’m tired of people using their passion to bash, bash, bash.
Maybe I just don’t get it, but if you’re a basher, please just move along. And if you still think I’m a Microsoft pawn, well, I’m not going to convince you, now am I?
Note to Robert Scoble: you had the temerity to criticize Apple and the zealots came out in force — even called you a Microsoft shill. Welcome back to our club, Robert — though I’m not sure you ever really left.
[tags]Digipede, Microsoft, HPC, Apple, Gillmor, Scoble, .NET, SC07[/tags]
Tags: .NET, Apple, Digipede, Gillmor, HPC, Microsoft, SC07, Scoble
November 6, 2007 at 10:31 am · Filed under Miscellaneous
Congratulations to the PowerShell team for getting out their CTP. I grabbed it this morning to make sure the Digipede AddIn works against it. Yes it does.
Cool stuff.
Couple of things:
- WS-MAN needs to be installed before installing the CTP (this What’s New post implies that the remote-shell features need it, but not that it is required). I hope this is only for the CTP and will not be required in the eventual release. Any extra requirements make it harder for ISVs to integrate PowerShell into their products. If you do not have WS-MAN installed yet, go here to get it: http://go.microsoft.com/fwlink/?LinkID=100350&clcid=0x409
- This new version comes with a “Graphical PowerShell”. This appears to be similar to the Shell Tools PowerShell Analyzer product, and not a replacement console. If you are looking for a better console, check out the other Shell Tools product, PowerShell+.
I will spend more time with the CTP soon and likely have more comments then.
[tags]Digipede, PowerShell, CTP, PowerShellV2, Microsoft, .NET[/tags]
Tags: .NET, CTP, Digipede, Microsoft, PowerShell, PowerShellV2
October 30, 2007 at 12:22 pm · Filed under .NET, Grid Computing, Miscellaneous
Today I was in a conference call doing a demonstration of the Digipede Network.
One of the demos includes using Excel as a front-end to a distributed code-behind calculation. A common follow on question was asked (heavily paraphrased),
what about code trapped in Excel workbooks?
The answer is, yes, we can (and have several customers that do) distribute Excel workbooks for distributed execution. Our software moves the workbooks, launches Excel through COM, executes calcs in the workbook, saves them, and brings back the workbook.
The prospect says,
That is both commendable and horrifying at the same time.
Heh.
As is most of the work we’ve done to provide stable, registration-free COM contract for the Digipede COM users.
[tags]Digipede, Excel, .NET, COM, QOTD[/tags]
Tags: .NET, COM, Digipede, Excel, QOTD
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
« Previous entries ·
Next entries »
About me
Main feed
Email subscriptions