September 2006 - Posts
In the last couple of weeks I created a windows service for my current assignment. In order to deploy this service I created an installer package which works fine. But the administrators at this company asked if I could set the default value for the "Install app for yourself, or for anyone who uses this computer" radio button group to anyone.
Of course, I said, silently laughing for being asked to do such a simple task. But boy, was I wrong!
The installer, like the windows service, was created using VS 2003. I tried looking for a property with which I could change the default value for that radio button group. And I couldn't. I tried Google and all I could find was that, unless I used VS 2005, I had to use an application called Orca to do this manually.
Set Everyone as default in installer
Suppose you want to have the "Everyone" option in the folder form of your installer to be the default. Then you would have to take the following steps to change this, once the MSI file has been created:
- Start Orca and open the MSI file you want to change.
- You will see two grids. The one on the left contains the tables in the MSI file, the one on the right the properties and values stored in that table.
- In the grid "Tables" look for the table Property and select that table.
- In the grid on the right, look for property FolderForm_AllUsers and select that property.
- Change the value to ALL.
- Save the installer and close Orca.
When you run the installer, you will see that the property is now set to "Everyone" instead of the "Just me" which is the regular default value.
Why is this not useful?
First of all, this works. And I could do this for my client. But why has Microsoft made this so difficult? I'm not the only one with this problem, and there are more options one might like to change. For example, you may wish to force a reboot after the installation has completed. Again something you need to do using Orca.
I'm forced to manually change this when I create a new installer. We're currently running tests on the application and for each fix we need to create a new installer. So you can image that I'm not too thrilled having to change this option by hand for each fix I need to deploy.
If there is anyone out there that has an better solution, please let me know. If it can be done by changing something in the VS 2003 installer project, that would be my first preference. If it can be done using a post-build action, again that would suit me just fine. I eagerly await any comments.
At my current assignment, we have a number of applications that log extensively into a SQL server 2000 database table. These applications log thousands of rows per day, so you can imagine that this table contains huge numbers of rows after only a few weeks.
We were asked to come up with a clean up procedure that will clean the log entries without locking to many rows at a time. We came up with a stored procedure which will be scheduled to run somewhere around midnight, when no one is working here. The table itself could be declared as follows:
CREATE TABLE [dbo].[LogInformation] (
[LogInformationId] [bigint] IDENTITY (1, 1) NOT NULL ,
[LogDate] [datetime] NOT NULL ,
[LogText] [varbinary] (50) NOT NULL
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[LogInformation] WITH NOCHECK ADD
CONSTRAINT [PK_LogInformation] PRIMARY KEY CLUSTERED
(
[LogInformationId]
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[LogInformation] WITH NOCHECK ADD
CONSTRAINT [DF_LogInformation_LogDate] DEFAULT (getdate()) FOR [LogDate]
GO
There is more information in the table, but I stripped it to what is used in the stored procedure we created. The following code shows this stored procedure:
CREATE PROCEDURE CleanLog
@daysToKeep int = 30, -- Leave 30 days of log untouched
@maxTotRows int = 100000, -- Delete no more than 100000 rows in total
@maxBatchRows int = 1000 -- Delete max. 1000 rows each batch
AS
BEGIN
DECLARE @batchRows int -- Deleted number of rows in current batch
DECLARE @maxID int -- Maximum PK-id to be deleted in the LogTable
-- Get the biggest PK-id within the criteria
SELECT @maxid = Max(LogInformationId)
FROM LogInformation (nolock)
WHERE LogDate > dateadd(day, @daysToKeep * -1, GetDate())
IF (NOT @maxID is NULL)
BEGIN
SET ROWCOUNT @maxBatchRows -- delimit rows per Batch
SET @batchRows = 1
-- keep deleting rows until: there are no more rows to delete OR
-- the maximum number of deleted rows is reached.
WHILE (@batchRows > 0) AND (@maxTotRows > 0)
BEGIN
IF (@maxTotRows > @maxBatchRows)
BEGIN
SET ROWCOUNT @maxTotRows
END
DELETE FROM LogInformation
WHERE LogInformationId <= @maxID
SET @batchRows = @@rowcount
SET @maxTotRows = @maxTotRows - @batchRows
END
END
END
It works fine, and as far as we can tell, the impact on database performance while the procedure is running is minimal. We came up with this solution because this way we don't need temp tables or cursors, and we do not create giant transactions that lock thousands of rows.
But maybe somebody out there has a better solution?
I was asked a question about this for a possible new assignment and obviously thought of the upgrade wizard that is part of the Visual Studio IDE. Just open the VB6 solution in Visual Studio and just follow the steps.
But there's obviously more to it than just running the wizard. I found extensive documentation at Microsoft's MSDN site. There is a lot of documentation about convertiing VB6 to VB.Net at MSDN. Simply follow this link. At this page you will find, among others, the following information:
- An Upgrade Assement tool. This tool analyzes the application components and the relationships between them from an upgrade perspective, considering elements, constructs, and features that consume resources during an upgrade. It generates a group of reports that are used for calculations related to task effort and cost
- An Upgrade Guide. This guide is intended for software technical decision makers, solution architects, and software developers who are involved in Visual Basic 6.0 application or component development. It helps you understand the issues and risks that go along with upgrading to Visual Basic .NET. It also provides steps for preparing your applications for a successful and cost-effective upgrade.
Sandcastle, Microsoft's solution to generate documentation using XML tags in your source code, is getting more and more momentum in the .Net community. I have been using it since the first CTP became available and so far I have been very happy with the results. Anand Raman, Microsoft's Group manager for Sandcastle, is actively looking at forums and provides constant feedback to questions. In this post, I will try to give you a small update about the current status of Sandcastle.
Sandcastle releases
September CTP
The September CTP has been released. It contains a number of bugfixes. A full list of fixes can be found here on the Sandcastle blog. One of the new features is a new set of transforms. These transforms will produce documentation with the look and feel of Visual Studio 2005. You can download the new CTP here.
RTW 1.0
The first RTW release is planned for October. And as the next CTP is planned for this week, I expect the RTW release to take place near the end of October. Again, it's not clear yet what will be in this release, but Microsoft promised to support a number of NDoc-Only tags. There was also talk of a GUI and VS add-in, but it has been quiet on that front since it was mentioned at the release of the July CTP. However, I haven't been let down on features and fixes by the Sandcastle team to this point, so I expect that this will still be the case.
Sandcastle Help File Builder
There are a lot of community tools available to help you use Sandcastle. I've tried several of them, and some weeks ago I decided to stick to the Sandcastle Help File Builder, created by Eric Woodruff. At least, until a better option becomes available.
This GUI application provides an NDoc like GUI for Sandcastle. if you're used to working with NDoc, this tool is just great. Everything looks and feels the same. Just like NDoc, the latest version of this tool allows you to create a documentation project by importing a Visual Studio solution.
If you have an NDoc project for your documentation, the tool is able to import that too. So switching to this application to generate your documentation is really easy.
This tool also allows you to add references to GAC assemblies. Sandcastle requires all references to be available. This includes GAC assemblies that are referenced by assemblies you reference. A lot of the times you don't add these references to your projects. Using this tool, you specify these GAC assemblies as references to the documentation project.
I'm back at work, writing VB.Net code again. As I blogged before, I'm currently assigned to a project where I need to develop software in VB.Net. And with a background in C#, it can be pretty annoying at times. I could write the code blindfolded in C#, but in VB.Net I still have to look for examples. But there's help in the way of some cool tools. So in this post, I will some up some options to convert code from one language to another.
SharpDevelop
SharpDevelop is an open-source IDE for building .Net applications. One of the built-in features is a conversion tool which allows you to convert code from C# to VB.Net and vice-versa. It's pretty good in converting. I use it extensively when I want to convert entire classes.
Scott Swigart Visual Studio Add-In
I recently found this article by Scott Swigart and the add-in he describes is actually quite good for my current situation. The add-in allows you to copy (or type) C# code in a text editor. Clicking a button simply adds the code as VB.Net code into your current project. The tool uses public webservices to perform it's task. It also comes with the source code, so it should be possible to add other services, or convert code from VB.Net to C#.
Carlos Aguilar Mares's AJAX-powered code converter
Yep, you read this right. An AJAX-powered website that converts code from C# to VB.Net and vice-versa. Have a look, it works really well. You can type the code and it's converted as you type. It's not that fast (yet), probably because of all the postbacks for everything you type.
Reflector
Reflector has an option that will convert the MSIL found in the assembly to C# or VB.Net. This option can be useful if you have a compiled assembly and not the code it self. But it's not fool proof, and when a tool like Dotfuscator is used, it isn't always a big help.
Yep, like many other's it's time for me, the wife and my daughter to go on a well deserved vacation. So don't expect to see any blog posts (or comments on posts by others) from this developer. I'll be enjoying beers and bratwurst and the german country side near Medebach, Hochsauerland, Germany.
CU in 2 weeks!
PS: I might blog about my vacantion on my family blog, in Dutch, but don't count on it too much :-)