We've been using external config files to manage separate dev.config / qa.config / prod.config settings for a while and it's worked pretty well. Pretty code sample here. The one difference here is that changes to the referenced external config files don't get picked up right away as web.config edits do, so we're always editing web.config to add / remove whitespace just so the ASP.NET application cache is invalidated and the app reloads, causing it to pick up the new config values.
What would be better is something like the unix touch command... from the right click menu...
I googled like mad and came up empty, so I decided to DoIt myself. While I was at it, I added a right click Backup function - it makes a copy of a file with .bak on the end - project.dll -> project.dll.bak, for instance.
Sadly, nothing fancy here - shell calls to the cmd copy function (you gotta edit it to command.exe if you're on Win98 / ME). The Touch command copies the file back over itself, giving it a new timestamp. The copy function checks for and prevents this, but it does support file concatenation so we just concatenate a nul. /b specifies binary mode which strips the null character, and /y says yes so you don't have to. And the best part - I'm really proud of this - it flashes the console window up on the screen to remind you of our glorious DOS heritage. Also because I couldn't figure out how to hide that. The Touch command is only added to config files, while the Backup command is added to all files (should I make Touch apply to all file types?). You can select multiple files and select Backup and it will get them all.
I've tested these a good amount, both locally and on mapped drives, but please blame Microsoft and not me if this eats your production web.config files. Let me know, though, so I can update this.
Or you can just save this text to a reg file and merge it:
Windows Registry Editor Version 5.00
@="cmd.exe /c copy %1+nul %1 /by"
@="cmd.exe /c copy %L %L.bak /by"
@="cmd.exe /c copy %1+nul %1 /by"
Epilogue: Just after finishing my masterpiece (see above), I saw that Steve McMahon (Mr. vbAccelerator) has done this before: vbAccelerator Touch Utility. If you haven't checked his site out lately, give it a look. Nice site, great stuff. I like my solution better, though - not just because it kept me up until 2 (at which point the baby woke up), but because mine is simpler, there's no exe file to accidentally delete, it takes 1/30th the disk space, and because Steve makes me feel stupid and I frankly resent it.
Just saw this on CodeProject: Dot Net Script. The innovative approach on this .NET script engine (as opposed to the others listed below) is an XML syntax to allow specifying assembly references and language.
.NET's powerful, but if I've gotta bang out a quick one off util, VBS or even BAT files seem to be much faster for me. .NET doesn't offer scripting languates. True, you can command line compile, but that works better in other peoples' demos than on my computer (opposite of "works on my machine" syndrome - I must have hardware problems).
SnippetCompiler's great for quick tests or one off utility type things. It's got a great UI with SemiIntelliSense, and I'm still convinced the MS folks bought Jeff off or he would have made a run at going head to head with VS. Still, sometimes I still yearn for a few scripts I can keep in a folder on my desktop... Also, the assembly references don't stay with the code, although I'm not sure how big a deal that is.
I've looked at Alintex Script .NET, which if a full featured product, but it looks a little more commandline-ish than I like, and it used to require a license for commercial use (although it looks like that's changed). I guess I should give it a more fair look.
And then there's NScript, another CodeProject... um.. project that I played with a while back. This one's really easy to use - you just write your code to .NCS or .NVB files and double click em. Hmmm... now I'm wondering why I've forgotten about these guys and keep dropping back to VBS or BAT files.
But I guess I also wonder why MS doesn't supply a .NET equivalent of CSCRIPT.EXE or WSCRIPT.EXE. It's a little thing, but it'd make the move to .NET seem a lot more inevitable if the utility and managment code was in a .NET tongue.
I seem to be collecting IE Explorer bars. Here's a fun new one:
Inline CSS Editor (download) is an IE Explorer bar addin that's apparently based on the EditCSS Mozilla Firebird plugin. When it's enabled, it shows the applicable CSS for any page you browse to. You can then edit the CSS and watch the page update as you change it. Useful for debugging your own CSS, for analyzing someone else's, or for seeing what MSDN would look like if they gone with Webdings as the default font.
Well, it's beta, but I'll take it - it adds HTML source code editor!
BlogJet 126.96.36.199 BETA Release Notes
February 11, 2004
* HTML source editor with highlighting and code completion.
* Indent/Outdent (for those who use <BLOCKQUOTE>'s).
* Link text and target in Insert Hyperlink dialog.
* Post Properties (allow comments/pings) for MovableType, Blogware and TypePad.
* Link insertion with drag-and-drop.
* Hotkeys for top-level menus.
* New progress indicator.
* New sweet icons for categories.
* New About window.
* DasBlog support.
* Fixed issues with View History in TypePad.
* Deleting entry now forces blog republish.
* Fixed issues with images path.
* Fixed deleting post which is being edited.
* Fixed various bugs with Micro Editing mode.
* Minor fixes.
string.Replace() is case sensitive. Regex.Replace isn't, though...
using System.Text.RegularExpressions;Obvious, but somehow I keep forgetting it... It'd be nice if string.Replace learned this trick some day.
string myString = "find Me and replace ME";
string strReplace = "me";
myString = Regex.Replace(myString, "me", strReplace, RegexOptions.IgnoreCase);
Oh, yes, it does.
If your previously working Managed DX code or samples stop working due to a missing reference, it's likely because a windows update with a newer DX end user runtime removed the SDK installed Managed DX dll.
Apparently the DX 9.0a end user runtime removed the Managed DX dll installed by the DX 9.0 SDK. This was probably fixed in the 9.0b end user runtime release. This wouldn't affect end user applications that ran on Managed DX, but it would prevent your Managed DX code from compiling.
1. Download the DirectX 9.0b Redistributable for Software Developers. Yep, it's a 35MB download.
2. Install with the /installmanageddx setting - "dxdevrtm.exe /installmanageddx"
If you've installed the DX SDK after the 9.0a end user runtime release this isn't a problem for you. Come to think of it, if you've never installed the DX SDK this probably isn't a problem for you.