During windows services development there are periods during the final deployment process where I'm installing and uninstalling services pretty rapidly on a server and I occasionally run into this message: "Error 1001. The specified service has been marked for deletion." This error message will cancel the installation and, if you Google around for cures to this problem, the general consensus is to reboot the system.
The systems I work on require extensive permissions from a lot of people/departments to reboot, bringing development to a halt, so I found an easier way to get around the problem. It turns out that the error message is actually complaining that "services.msc" is currently open (in my case, I've left the server manager app open to list current service statuses), so stopping this process (again in my case, simply closing server manager) allows the service to be installed.
Friday, November 4, 2011
Thursday, September 22, 2011
Glitch in setting up a setup-deployment project for 64-bit apps in Visual Studio 2010
I have a windows service that was originally developed for 32-bit machines that I converted to 64-bit. The original setup/deployment project would not compile properly, though, and I would get this error message when attempting a build under Visual Studio 2010:
"File '64bitWindowsService.exe' of project output 'Primary output from 64bitWindowsService (Active)' targeting 'AMD64' is not compatible with the project's target platform 'x86'"
Getting past this problem was easy: Examine the properties of the setup project and change its "TargetPlatform" setting from 'x86' to 'x64'"
The setup/deployment project would then build OK but when I would try and do an install thru Visual Studio (by right-clicking on the project and selecting 'Install') I'd get another error message:
Error 1001: Exception occurred while initializing the installation: System.BadImageFormatException: Could not load file or assembly 'file:///C:\Program Files\Microsoft\Setup1\64bitWindowsService.exe' or one of its dependencies. An attempt was made to load a program with an incorrect format.
Here the solution came from resetting the "Platform Target" of the windows service from "x64" to "Any CPU" (right click the windows service project, select "Properties", and click on the "Build" tab). Once that is set it seems to build and install OK.
"File '64bitWindowsService.exe' of project output 'Primary output from 64bitWindowsService (Active)' targeting 'AMD64' is not compatible with the project's target platform 'x86'"
Getting past this problem was easy: Examine the properties of the setup project and change its "TargetPlatform" setting from 'x86' to 'x64'"
The setup/deployment project would then build OK but when I would try and do an install thru Visual Studio (by right-clicking on the project and selecting 'Install') I'd get another error message:
Error 1001: Exception occurred while initializing the installation: System.BadImageFormatException: Could not load file or assembly 'file:///C:\Program Files\Microsoft\Setup1\64bitWindowsService.exe' or one of its dependencies. An attempt was made to load a program with an incorrect format.
Here the solution came from resetting the "Platform Target" of the windows service from "x64" to "Any CPU" (right click the windows service project, select "Properties", and click on the "Build" tab). Once that is set it seems to build and install OK.
Friday, August 26, 2011
Removing a Visual Studio 2010 solution from TFS source control
A Google search on this brought up a lot of intimidating-looking solutions requiring text-editing the ".sln" file, but a simpler and easier solution was available in the VS2010 interface itself.
- Select the solution in the Solution Explorer
- Click on the "File" menu item
- Click on "Source Control"
- Click on "Change Source Control"
Select the solution from the datagrid, then click on "Unbind"
- Select the solution in the Solution Explorer
- Click on the "File" menu item
- Click on "Source Control"
- Click on "Change Source Control"
Select the solution from the datagrid, then click on "Unbind"
Monday, August 1, 2011
Images and CSS missing from IIS7 website
I'm moving a website from IIS6 running on a Windows 2003 server to IIS7 running on a Windows 2008 server and was having a fairly smooth time of it until I first tried to view the default web page from the local host. It looked like only the controls specifically updated by ASP.NET were being shown -- all the static content, including images, were missing and and the css files were clearly not applying any formatting.
The problem was straightforward and could be traced to my installion of IIS7: compared to IIS6, IIS 7 offers such a higher level of control and granularity in its installation that I neglected to specifically enable "static content" in the web server. I'd assumed, and you know what happens when you assume.
By going into control panel and asking to add "Windows Features," and then updating the web server role, the missing option presented itself pretty clearly as "not installed." After installing it, the website worked pretty much as it did before.
The problem was straightforward and could be traced to my installion of IIS7: compared to IIS6, IIS 7 offers such a higher level of control and granularity in its installation that I neglected to specifically enable "static content" in the web server. I'd assumed, and you know what happens when you assume.
By going into control panel and asking to add "Windows Features," and then updating the web server role, the missing option presented itself pretty clearly as "not installed." After installing it, the website worked pretty much as it did before.
x
Friday, July 8, 2011
ASP.NET "Invalid postback or callback argument. Event validation is enabled ..." error
I'm working on a page which features a user control which contains a datagrid with "Select" buttons in each row.
During initial development of the page the same datagrid was placed directly in the content section of a page and its behavior was normal; when this datagrid and other controls were put into a user control and the user control added to the page I began getting this error;
"Invalid postback or callback argument. Event validation is enabled usingin configuration or <%@ Page EnableEventValidation="true" %>in a page. For security purposes, this feature verifies that arguments to postback or callback events originate from the server control that originally rendered them. If the data is valid and expected, use the ClientScriptManager.RegisterForEventValidation method in order to register the postback or callback data for validation."
I checked to make sure that the user control was registered in the page that was hosting it -- it was -- so I was a little puzzled at why the host page wasn't recognizing the user control.
Googling the problem turned up a lot of responses saying that changes could be made in the config file to turn off this security feature but this seemed a little kludgy.
Tracing the problem in the debugger I found that the failure was occuring during the Page_Load event in the page lifecycle of the user control and failing on the code in that event handler. I moved the code that was in the "Page_Load" event handler into the 'Page_Prerender" event handler and this problem stopped.
I am not quite sure why this worked, I'll write a comment to this blog entry if I figure it out.
During initial development of the page the same datagrid was placed directly in the content section of a page and its behavior was normal; when this datagrid and other controls were put into a user control and the user control added to the page I began getting this error;
"Invalid postback or callback argument. Event validation is enabled using
I checked to make sure that the user control was registered in the page that was hosting it -- it was -- so I was a little puzzled at why the host page wasn't recognizing the user control.
Googling the problem turned up a lot of responses saying that changes could be made in the config file to turn off this security feature but this seemed a little kludgy.
Tracing the problem in the debugger I found that the failure was occuring during the Page_Load event in the page lifecycle of the user control and failing on the code in that event handler. I moved the code that was in the "Page_Load" event handler into the 'Page_Prerender" event handler and this problem stopped.
I am not quite sure why this worked, I'll write a comment to this blog entry if I figure it out.
Saturday, June 18, 2011
The problem of Microsoft C# Datasets and SQL Server stored procedures which use temporary tables
In certain cases when coding up stored procedures I sometimes needed to create a temporary table "on the fly" to hold specialized output (generally I've done this when I needed to scan several tables looking for "most recent" records from each or needed to compose a table of summary information gathered from various tables in the database). To date I've been used to using the T-SQL "create #temptable" syntax.
Traditionally the coding of these small sprocs consisted of 1) creating this temp table, 2) adding rows to it, and 3) ending the sproc with a "select * #temptable" statement to output the results.
This has worked fine for me for years for handling custom summary queries but I discovered that if I tried adding these types of sprocs to a C# dataset I couldn't get them to work. Specifically, when I added the sproc to a project's dataset in Visual Studio 2008 the "wizard" would dutifully add the procedure itself to a "QueriesTableAdapter" collection but would not create an associated table.
This made sense, I guess, since ADO really has no idea what the schema of "#temptable" is in the sproc and could not create a strongly-typed table object from it.
The solutions found in Google searches were not satisfactory until I came across the new (for me at least -- it's actually been around since SQL Server 2005) SQL Server "table variable." It's a significantly more elegant solution than "temptables."
Start the coding of the sproc with the definition of a "table variable" to hold the summary information, e.g.:
DECLARE @AGENCYSUMMARY TABLE
(
agencycode varchar(50)
, entitycode varchar(50) PRIMARY KEY
, scanjobid int
, rows int
, timein datetime
, timeout datetime
)
then write the code to add rows to this table and, at the end of the sproc, add a SELECT statement to dump all the information in the table variable to the output stream:
SELECT agencycode
, entitycode
, scanjobid
, rows
, timein
, timeout
from @AGENCYSUMMARY
Now when you edit a dataset using Visual Studio and add this sproc to the design screen the tableadapter AND the table will appear. Evidently the initial definition of the schema of the table variable provides the dataset with what it needs to handle this "temporary" table and it creates a strongly-type table object just as it would for any other table defined in the database.
Traditionally the coding of these small sprocs consisted of 1) creating this temp table, 2) adding rows to it, and 3) ending the sproc with a "select * #temptable" statement to output the results.
This has worked fine for me for years for handling custom summary queries but I discovered that if I tried adding these types of sprocs to a C# dataset I couldn't get them to work. Specifically, when I added the sproc to a project's dataset in Visual Studio 2008 the "wizard" would dutifully add the procedure itself to a "QueriesTableAdapter" collection but would not create an associated table.
This made sense, I guess, since ADO really has no idea what the schema of "#temptable" is in the sproc and could not create a strongly-typed table object from it.
The solutions found in Google searches were not satisfactory until I came across the new (for me at least -- it's actually been around since SQL Server 2005) SQL Server "table variable." It's a significantly more elegant solution than "temptables."
Start the coding of the sproc with the definition of a "table variable" to hold the summary information, e.g.:
DECLARE @AGENCYSUMMARY TABLE
(
agencycode varchar(50)
, entitycode varchar(50) PRIMARY KEY
, scanjobid int
, rows int
, timein datetime
, timeout datetime
)
then write the code to add rows to this table and, at the end of the sproc, add a SELECT statement to dump all the information in the table variable to the output stream:
SELECT agencycode
, entitycode
, scanjobid
, rows
, timein
, timeout
from @AGENCYSUMMARY
Now when you edit a dataset using Visual Studio and add this sproc to the design screen the tableadapter AND the table will appear. Evidently the initial definition of the schema of the table variable provides the dataset with what it needs to handle this "temporary" table and it creates a strongly-type table object just as it would for any other table defined in the database.
Thursday, June 9, 2011
Grep'ing files in Windows 2008 with PowerShell
For the life of me I can't get the windows search function to work correctly under Windows 2008 to do full-text recursive searches of a directory tree -- supposedly you need to reset the folder options under Windows to search file contents but it just doesn't work right.
Here's a simple way to do it using PowerShell:
Here I'm doing a recursive full-text search of a directory tree for files containing the string '.toggle' (it's a JQuery function I used sometime over the last year that I needed an example of).
This works well and, unlike the built-in Windows "search" function (quotes are intentional), its operations are transparent and actually work.
Here's a simple way to do it using PowerShell:
PS> get-childitem d:\ -include *.aspx -recurse select-string -pattern '.toggle'
Here I'm doing a recursive full-text search of a directory tree for files containing the string '.toggle' (it's a JQuery function I used sometime over the last year that I needed an example of).
This works well and, unlike the built-in Windows "search" function (quotes are intentional), its operations are transparent and actually work.
Subscribe to:
Posts (Atom)