gordon.byers.me - Page 12 of 14 - my code scratchpad

November 28, 2014

Netsuite API Error – This document you requested has moved temporarily

Immediately after downloading the latest WSDL, I started getting an error back from the login method. “This document you requested has moved temporarily”, the url is the one from the Netsuite Platform Guide : https://webservices.netsuite.com/wsdl/v2014_2_0/netsuite.wsdl

As per the error, the default URL was indeed wrong. However the URL it suggests in the error message is

https://webservices.na1.netsuite.com/dcrf.nl?k=58baee60ac4e3c16a1765edcb0b3a51e8c6d4b154b13db1f603dd219435cc15d&amp;dcrdt=%2Fservices

1	https://webservices.na1.netsuite.com/dcrf.nl?k=58baee60ac4e3c16a1765edcb0b3a51e8c6d4b154b13db1f603dd219435cc15d&dcrdt=%2Fservices

Which doesn’t work either.

The actual URL that you’ll want to use is

https://webservices.na1.netsuite.com/services/NetSuitePort_2014_2

1	https://webservices.na1.netsuite.com/services/NetSuitePort_2014_2

For more about Netsuites Suitetalk API see http://gbyers.byers.me/?p=401

May 20, 2013

HttpWebRequest throws “The specified registry key does not exist.”

Encountered a strange issue today, upon executing the following line of code, a “The specified registry key does not exist.” error was thrown.

A little googling reveals that the cause was a windows security update that was rolled out at work: MS12-074

HttpWebRequest wreq = (HttpWebRequest)WebRequest.Create(url);

1	HttpWebRequest wreq = (HttpWebRequest)WebRequest.Create(url);

Here’s a quote from the Microsoft KB article;

To enable the legacy functionality of WPAD, create the LegacyWPADSupport value in the following registry subkey:

Registry location: HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFramework
DWORD (32-bit) Value name: LegacyWPADSupport
Value data: 1

The fix was to create the registry key with a value of 0.

November 20, 2012

Claiming back SQL Log space

I recently had the problem where one of our staging database servers had run out of disk space It contained about 40 databases, each of which was set to Full Recovery mode.

The maintenance jobs had been turned off which meant the log files of each of the databases had grown (the average was a 6gb log) I needed a way to claim back this disk space and without too much effort, and with no regard to what was in the logs. Here’s what i came up with.

It iterates through all databases on an instance of SQL,

CREATE TABLE #tmpDatabases
(
   RowID int IDENTITY(1, 1), 
   [dbId] int,
   dbName VARCHAR(255), 
   recoveryModel int,
   ldfName varchar(255), 
   oldLdfSize int, 
   newLdfSize int,
   mdfName varchar(255), 
   mdfSize int
)

INSERT INTO #tmpDatabases 
select d.database_id, d.name, d.recovery_model, ldf.name [LdfName], ldf.size [LdfSize], 0, mdf.name [MdfName], mdf.size [MdfSize]
from sys.databases d
inner join sys.sysaltfiles ldf on d.database_id = ldf.dbid and ldf.filename like '%ldf'
inner join sys.sysaltfiles mdf on d.database_id = mdf.dbid and mdf.filename like '%mdf'
where d.database_id&gt;4 --only user databases

DECLARE 
@RecoveryModel int,
@DbName varchar(255),
@DbId int,
@LdfName varchar(255),
@SQLUse nvarchar(1024),
@NumberRecords INT,
@RowCount INT

-- Get the number of records in the temporary table
SET @NumberRecords = @@ROWCOUNT
SET @RowCount = 1

WHILE @RowCount  3
	BEGIN
		SET @SQLUse = 'ALTER DATABASE ' + @DbName + ' SET RECOVERY SIMPLE WITH NO_WAIT; '
		EXEC sp_executesql @SQLUse
	END

	--Shrink log file
	SET @SQLUse = 'USE ' + @DbName + '; SELECT DB_NAME() [Current Db]; CHECKPOINT; DBCC SHRINKFILE(' + @LdfName + ', 50); '
	EXEC sp_executesql @SQLUse

	--get new log file size
	update #tmpDatabases
	set newLdfSize = ldf.size
	from #tmpDatabases
	inner join sys.sysaltfiles ldf on #tmpDatabases.[dbid] = ldf.dbid and ldf.filename like '%ldf'
	where #tmpDatabases.[dbId] = @DbId

	--output progress
	select * from #tmpDatabases where #tmpDatabases.[dbId] = @DbId

	SET @RowCount = @RowCount + 1
END

select *, oldLdfSize-newLdfSize [LdfDiff] from #tmpDatabases order by oldLdfSize-newLdfSize desc

drop table #tmpDatabases

CREATE TABLE #tmpDatabases

(

RowID int IDENTITY(1, 1),

[dbId] int,

dbName VARCHAR(255),

recoveryModel int,

ldfName varchar(255),

oldLdfSize int,

newLdfSize int,

mdfName varchar(255),

mdfSize int

)

INSERT INTO #tmpDatabases

select d.database_id, d.name, d.recovery_model, ldf.name [LdfName], ldf.size [LdfSize], 0, mdf.name [MdfName], mdf.size [MdfSize]

from sys.databases d

inner join sys.sysaltfiles ldf on d.database_id = ldf.dbid and ldf.filename like '%ldf'

inner join sys.sysaltfiles mdf on d.database_id = mdf.dbid and mdf.filename like '%mdf'

where d.database_id>4 --only user databases

DECLARE

@RecoveryModel int,

@DbName varchar(255),

@DbId int,

@LdfName varchar(255),

@SQLUse nvarchar(1024),

@NumberRecords INT,

@RowCount INT

-- Get the number of records in the temporary table

SET @NumberRecords = @@ROWCOUNT

SET @RowCount = 1

WHILE @RowCount 3

BEGIN

SET @SQLUse = 'ALTER DATABASE ' + @DbName + ' SET RECOVERY SIMPLE WITH NO_WAIT; '

EXEC sp_executesql @SQLUse

END

--Shrink log file

SET @SQLUse = 'USE ' + @DbName + '; SELECT DB_NAME() [Current Db]; CHECKPOINT; DBCC SHRINKFILE(' + @LdfName + ', 50); '

EXEC sp_executesql @SQLUse

--get new log file size

update #tmpDatabases

set newLdfSize = ldf.size

from #tmpDatabases

inner join sys.sysaltfiles ldf on #tmpDatabases.[dbid] = ldf.dbid and ldf.filename like '%ldf'

where #tmpDatabases.[dbId] = @DbId

--output progress

select * from #tmpDatabases where #tmpDatabases.[dbId] = @DbId

SET @RowCount = @RowCount + 1

END

select *, oldLdfSize-newLdfSize [LdfDiff] from #tmpDatabases order by oldLdfSize-newLdfSize desc

drop table #tmpDatabases

September 20, 2012

Installshield LE for Visual Studio 2012 : x64 support

When Microsoft released Visual Studio 2012 on the 16th of August 2012, I was disappointed to learn that they had removed support for the Setup and Deployment project types.

InstallShield Limited Edition (ISLE) is free for Visual Studio developers and replaces the functionality of the project templates in Visual Studio for setup and deployment.

Ref: http://msdn.microsoft.com/en-us/library/2kt85ked.aspx

Fortunately you can still open an VS2012 solution files with VS2010, and continue to use the Setup and Deployment functionality from there. However you’ll have problems when the applications/assemblies you want to package are using .NET 4.5 as VS2010 will not support those projects.

This left me in a bit of a pickle as i’d pushed the .NET version to 4.5, which left me the option of using Installshield Limited Edition for Visual Studio. However the version on the Installshield website was labelled as targeting Visual Studio 11. Proceeding to download it, and install it revealed it didn’t work with VS2012 at all. Thankfully last week I stumbled across a blog announcing SP1 to Installshield 2012, and the Installshield LE for Visual Studio has also been updated to support Visual Studio 2012 RTM.

Downloaded, installed and it works!! Woo hoo. The Installshield UI has been crammed into the Visual Studio IDE, but it works well. Instead of disabling options you can’t use, they’ve left them enabled with the a “sales pitch” screen appearing when you click on them (fair enough).

I created the installer for my windows service pretty quickly, built it and noticed that it wanted to deploy to C:program files (x86) and not my usual C:program files directory. After a little googling, it seems that the Limited Edition is just that, and x64 installations are not supported.

Workaround?

The usual predefined folder of ProgramFiles64 is not present, and when you try to install to [WindowsVolume]Program files it gets corrected to [WindowsVolume]Program files (x86). As installscript is disabled in Installshield 2012 LE, i can’t do much else to fool it. The good news is that because it’s just a file copy that Installshield is doing and my assemblies are set to Any Cpu they still run as x64 processes.

It’s not just the file copying that’s affected by Installshield 2012 not having “Enhanced 64-bit application support”, registry entries are put into the Wow6432Node part of the registry. Registry settings being in the wrong location is something that i can handle in my code… (that’s another blog post).

I did look at trying to leverage the Visual Studio ClickOnce deployment to deploy my windows service, but it’s not really doable for the following reason;

ClickOnce does not support custom destination folders. The reason why ClickOnce-deployed applications are installed into the cache is that such cache is maintained by the .NET Framework, which is responsible for executing applications deployed via ClickOnce.
Ref: http://social.msdn.microsoft.com/Forums/en-US/vbide/thread/997a0b71-3af7-49e8-9d8d-2b23655fa4d3

So what’s the solution?

If you don’t care about the fact that the files get installed to the x86 program files folder and you can fix any other issues in your app then use Installshield 2012 LE.

If you don’t mind using VS2010 and you are using .NET4 or below then that’ll still work.

Otherwise unless you want to roll your own solution, you’ll have to use a separate installation program such as Installshield 2012 Pro.

May 22, 2012

Google Chrome – Kerberos, Delegation, Negotiation, Auth

One of my more recent jobs was setting up a webservice that is both separated from the web application box and in need of the windows credentials of the original caller. After discovering a lot of the pain around SPN’s and kerberos where I found myself bound to internet explorer, I was really keen to get it working in my browser of choice.
(I’m using Windows 7 and my web applications are on a windows domain).

There is the mention of various websites of using the parameter –auth-negotiate-delegate-whitelist when starting Chrome..
This never worked for me.

What did work is documented here http://dev.chromium.org/administrators/policy-list-3#AuthNegotiateDelegateWhitelist
Basically, just adding a registry entry to specify your whitelist of servers.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESOFTWAREPoliciesGoogleChrome]
"AuthNegotiateDelegateWhitelist"="myserver,myotherserver,*.mydomain.local"

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESOFTWAREPoliciesGoogleChrome]

"AuthNegotiateDelegateWhitelist"="myserver,myotherserver,*.mydomain.local"

What the document doesn’t tell you is that after making the registry change, you have to reboot for the change to take effect, just by exiting chrome or killing the chrome process won’t cut it. After making the change, close Chrome and ensure you kill any of the resident Chrome processes with task manager.