I use Vista running on a Virtual PC as my development environment (I used to use WinXP, but then came along Windows Azure which required either Vista or Win Server 2003). The usage of SQL Server Management Studio on the Virtual PC was slowing down the system. So, I wanted to use my Host Operating System to access the SQL Server using SQL Management Studio. By default the SQL Server engine is configured to minimise the surface of attack. So, remote access to the sql server engine is also not enabled.
To access remotely, the TCP/IP protocol needs to be enabled, using the SQL Server Configuration Manager.
There after, it is recommended to allow remote connections via specified ports. So, I did that as shown below.
To test the configuration, I used a command from the remote computer.
Thumbs up. There were no error messages displayed after executing the above command
I expected a nice little text box in the SQL Server Management Studio connection dialog where I could specify the TCP/IP port number. It turns out there isn't and that I could simply append the port number in the same way I tested from command line.
That's it, a little burden outsourced to the Host PC.
I run a Virtual PC with Vista 32-bit as Guest operating system for my software development purposes. This VPC is quite slow despite taking measures to shut down various background services.
For reasons beyond my understanding (and me not willing to investigate on it), whenever a MMC console window is opened, CPU usage spikes to 100%. It was frustrating to to start SQL Server Engine by going to the services.msc console. So, I found a way to start SQL Server service from command line.
Please click on above image to see the command in clarity.
Having decided on giving the WCSF a try, I had a pretty smooth experience with installing WCSF.
The February-2008 release of WCSF does not use the Enterprise Library 4.0. It uses Enterprise Library 3.1. Although, the EntLib 3.1 is sufficient for WCSF-Feb'08, it just feels good to have and build upon the latest version. It took a few careful steps to get the WCSF working with EntLib 4.0. And even after that, at times, the guidance packages generate code that still uses EntLib3.1. This is not a major problem because I was able to re-reference the projects to the latest EntLib 4.0 assemblies.
The foremost concept to understand is the Modular structuring of the Web Application.
Then comes the understanding of Model-View-Presenter pattern. It took a while for me to figure out the role of Controller.
There is also the concept of a Service that gets consumed by a Controller. This Service has nothing to do with Web Services.
In fact, there is much more fundamentals to understand than I could discover in the hands-on-lab sessions.
The best resource (and by far the best writing) to explain concepts related to WCSF is Simon Ince's blog series. His posts made me understand the purpose of WCSF and have also inspired me on the various architectural considerations.
and now after CVS it's time to try out SVN
Yesterday, I was finally determined to make my machine a build system(with WinXP SP2 Pro) for which I had to install and configure CruiseControl.NET
. For which I had to install VSS. Then I thought of CVS (because, I was comfortable with CVS way of doing things for the past 1 year). Oh...then I thought of SVN (because, SVN is to be a compelling replacement for CVS).
The best part of SVN is the availability of the free e-book which is quite exhaustive. I was indeed more happy to read the TortoiseSVN
e-book because it gave detailed steps to install the SVN Server and not just the TortoiseSVN Client.
Since I did not have Apache Web Server in my system, I prefered the SVNServe type of SVN Server which listens on port 3690. With that I had my svn server setup but before running the server, I read a piece of information in the book which said that the svnserve.exe can be run as a windows service using a wrapper called SVNService
. Without much thought, I tried running the svnserve as windows service.
But, to my despair when I tried to view the repository which I had just created using TortoiseSVN, I could not find the repository using the repo-browser of TortoiseSVN. Something has gone wrong somewhere....After 30 minutes, I started to suspect the SVNService wrapper. So, instead of going to that level of abstraction, I decided to run the svnserve manually using command prompt. And lo there was Windows XP SP2 in action asking my permission to unblock the port 3690. Phew! that was a relief. After unblocking it, I reverted back to SVNService.
There ended my initial adventure with SVN which was quite less exciting than my earlier ones with CVS and TortoiseCVS. I am expecting the real thrill when I start using ASP.NET application with SVN.