After sticking with NAnt for quite some time, I decided to check-out MSBuild. So I downloaded the latest CTP and tried my first build-script.
Well, so far MSBuild looks quite similar to NAnt. You got your targets and properties, dependecies and stuff. Just MSBuild comes kinda plain, you don’t get that much tasks as you get with NAnt, but adding community tasks to MSBuild does some tricks.
OK, so I will try to rebuild my existing NAnt scripts to work with MSBuild … lets see how this works!
Well, sometimes the built-in MMC snap-in doesn’t do it all. In this case you need to do more than just add another user. Of course there a bunch of different ways to access your Active Directory. You most certainly can write a nifty c# programm, which could do all kinds of operations. But a lot of times you will end up write some little VBScript, just because it’s so darmn simple.
For the purpose of illustrating the usage of Active Directory scripting I have a little sample setup. Assume you have a database containing employee data and you want to sync this data with your Active Directory instance. You could further use this data in Active Directory to enable Active Directory aware programs (like SharePoint š ) to access this data.
OK; to get started I will show a little script, which access the Active Directory and does some mass-updating off user-accounts. For example say you want to add employee-numbers to the users accounts.
First of all, you need to connect to the directory. For this you need to know the root path of your Active Directory, or as a convenience you might as well useĀ LDAP://RootDSE instead. OK, let’s get connected to our Active Directory; the code below assumes you have a recordset calledĀ rstEmployees which holds our employee data. So we iterate over the recordset:
Sub UpdateActiveDirectoryEntries
On Error Resume Next
Dim objRoot, objUser
Dim intEmployeeCount
Set objRoot = GetObject(strRootADPath)
WScript.Echo "Processing records ..."
rstEmployees.MoveFirst
While Not rstEmployees.EOF
WScript.Echo "processing:" & rstEmployees.Fields("EmployeeName") & " (" & rstEmployees.Fields("EmployeeNumber") & ")"
Set objUser = GetObject("LDAP://CN=" & rstEmployees.Fields("EmployeeName") & "," & strAllEmployeeADPath)
If objUser Is Nothing Then
WScript.Echo "User '" & rstEmployees.Fields("EmployeeName") & "' could not be found!"
Else
ShowUser objUser
WScript.Echo "Writing ..."
objUser.Put "EmployeeID", rstEmployees.Fields("EmployeeNumber").Value
objUser.Put "EmployeeNumber", rstEmployees.Fields("EmployeeNumber").Value
' objUser.PutEx ADS_PROPERTY_CLEAR, "EmployeeNumber", vbNullString
objUser.SetInfo
ShowUser objUser
End If
Set objUser = Nothing
rstEmployees.MoveNext
Wend
End Sub
Finally … there is a new trailer for Duke Nukem 4-ever available … check it out!
BTW: “when it’s done” is still the way to go …
Well, quite a while ago I had massiv trouble with the ICQ-connectivity of my Miranda messanger. Upgrading to build #5 solved at least the problem concerning Trillian users.
Unfortunatly there seems to be still some trouble, concerning the visibility of ICQ-users as I already state in my forum post.
I just came across an interesting blog-post concerning the testing of biztalk pipelines. Unfortunatly I don#t have any biztalk-projects right now, so I can’t really try this, but I will try to use this as soon as a new biztalk-project is coming up!
Ayende just came up with a great startup-idea …
MSBuild comes only with a limited set of tasks, so it’s not very supprising to find a whole bunch of commnity tasks available.
The folks at tigris offer a nice bundle of tasks. There you’ll find a MSI installer. But unfortunatly the MSI doesn’t seem to install correctly, at least not when you’re not running an english version of visual studio.
To fix this problem, just go to [ProgramFilesFolder]\Microsoft Visual Studio 8\Xml\Schemas. Here you’ll find a folder representing your current locale (most like not 1033. So just copy your folder and rename it to 1033. This time the MSI will succeed.
Hiding classes and implementation in assemblies to the outside world is a good thing. This way you can only expose valid interfaces to the outside and have a bunch of helper classes/methods to the number-crunching, while being marked internal or private.
But there is this thing called unit-testing. You sometimes have internal classes that are being used in some context, but you might need to test them from you unit-testing assembly. Or you want to expose certain interfaces only to a limited assembly. In this case the friend comes in handy. Prior to .Net 2.0 this was not possible to do …
But .Net 2.0 introduced the friend-concept. To mark an assembly to be a friend of some other assembly just add:
[assembly: InternalsVisibleTo("Com.Acme.Testing")]
This way all internal classes/members of the assembly Com.Acme.Business can be called by the assembly Com.Acme.Testing.
Ok, you’re visual studio is most likely already kinda stuffed, after installing .Net 3.0 and adding the WF-Extension to Visual Studio 2005 and adding the WCF & WPF Extension you got a bunch of new Project and Item Templates.
So here’s another one!
Initially WiX was only a bunch of command-line tools that would turn some xml-files into a nice installer :). Well, with the introduction of Votive there also comes the first usable integration into visual studio. You still have to deal with XML, but at least the commandline tools like candle.exe, light.exe and dark.exe are hidden within the build-process which is being handled by msbuild.
So instead of using the plain-old-setup-project you can now add a wix-installer project to your solution and customize the install-process to your personal needs. Your first stop to get started would be the wix homepage.
This has been an issue for quite some time now, and I finally got around to actually do (and write about) it.
OK, imagine this: your setup your VMWare, install software and stuff … and after a couple of months you realize that you underestimated the capacity needs of your installation. So what should you do next, besides panic?
There is another solution (well, panic is still the #1 option!): you just resize your disk! As easy as this is said, the actual process is a little more complex.
select volume [number of the volume to extend] extend filesystem
Look at MSDN for more Information about Diskpart.
Voila! This should be all.