How to write to the disk (make a writable folder) in ASP.NET

To do file uploads, some administration is always necessary on the server side. ASP.NET tries very hard to prevent users from writing anywhere on the server, so we have to take special steps if file upload is required. In particular, the IIS7 server will not let you both Execute and Write into the same folder. For the record, here are the steps for IIS7 on Windows Server 2008 (assuming you are system administrator on the server):

* the user creates an uploads folder and sends its file spec to the administrator
* the administrator opens the Internet Information Services (IIS) Manager, browses to that folder, and right clicks over it to change file permissions as follows for the NETWORK SERVICE account:
** remove Read and Execute permission
** add Write permission

Both permissions should be changed in one step, and that should be all that is necessary. But test the write and subsequent read carefully; if either does not work, delete the folder, create a new one, and start all over again.

If you are using a hosting service, there should be some special procedure to get the permissions changed. In my experience, changing the permissions for this purpose has spotty success and can lead to a drawn-out hassle. I suppose it's worth it to have a reasonably secure server.

VS.NET 2010 fails to compile program created earlier in VS.NET 2008

Trying to recompile a program in Visual Studio 2010, which was originally created using Visual Studio 2008 (which is still on my PC), I got this baffling message:

Error 9 Task failed because "sgen.exe" was not found, or the correct Microsoft Windows SDK is not installed. The task is looking for "sgen.exe" in the "bin" subdirectory beneath the location specified in the InstallationFolder value of the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v6.0A. You may be able to solve the problem by doing one of the following: 1) Install the Microsoft Windows SDK for Windows Server 2008 and .NET Framework 3.5. 2) Install Visual Studio 2008. 3) Manually set the above registry key to the correct location. 4) Pass the correct location into the "ToolPath" parameter of the task.

These suggestions were too bizarre even to consider, and so I Googled. Right away, I found this nice blog entry which helped me out, and just in case it were to go away, I'm duplicating the helpful information it contains below. So, courtesy of the "dukelupus" blog, everything after this paragraph is copied verbatim from that blog.

Changing the registry key will not help nor will adding C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\ to the path. I did not try other solutions...I used FileMon to check what Visual Studio is looking for – and it appears that it will always look for that file at C:\WINDOWS\Microsoft.NET\Framework\v3.5\, which does not contain sgen.exe.

Just copy sgen.exe from C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\ to C:\WINDOWS\Microsoft.NET\Framework\v3.5\ and everything will now compile just fine. Here, to make your life easier, copy command:

copy /y “C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\sgen.exe” “C:\WINDOWS\Microsoft.NET\Framework\v3.5\”

Good luck!

ODBC workaround (Access to SQL Server) for 64-bit Windows 7

I've been avoiding 64-bit Windows due to various incompatibility rumors, but this case takes the cake, as it is entirely Microsoft's fault. My work place uses a variety of shared Access databases, located on a network drive, that connect via ODBC System DSN's to a SQL Server 2008.

Even though all DSN's appeared to be configured correctly on my colleague's brand new (64-bit) Windows 7 machine, and the ODBC connections passed their test, the actual database declined to connect to the server. Thanks to various discussion groups, we finally figured out that the graphical user interface accessible from the Administrative Tools applet in Control Panel actually brings up a 64-bit ODBC application, whereas we (for backwards compatibility) needed the strangely hidden 32-bit System DSN window. To run it, we had to browse to this path:

C:\Windows\SysWOW64\odbcad32.exe

Clicking on odbcad32.exe runs the 32-bit version of the ODBC connection setter upper. There, we re-created all the System DSN's, and finally the Access databases were happy.



By default, the Windows GUI is presenting a 64-bit ODBC connection setter upper (which I believe is in the C:\Windows\system32 path somewhere. Going manually to the first path and running the application, then adding the ODBC connections, makes it work.

In the meantime, 3 days of work were lost to this problem.

Sql Server Management Studio 2008 logon persistence problem

I very often open SQL Management Studio 2008 for the same server. Problem is, the very first time I accessed this server, I did so using a different user name and password. Forever after henceforth, SQL Management Studio refused to remove this old server entry from my dropdown list in the "Connect to Server" popup window.

This made it necessary to click to change the user and enter a new password about 80 times per day--all because this premium, allegedly very smart sophisticated software has decided never to forget a former entry--even though I have deleted the Registered Server and recreated and so forth. I'm frankly angry about this nuisance, which wouldn't matter if I didn't have to open and close the tool so many times per day.

If anyone has any concrete suggestion on how I can defeat this thing, please let me know. I see from the internet that I am not the only one having this frustration, but I have yet to find any blog entry or suggestion to alleviate the problem.

UPDATED with an answer in Aug. 2010:

For Sql Server Management Studio 2008 on Windows XP, to restart all your logins, delete the file:

C:\Documents and Settings\%username%\AppData\Roaming\Microsoft\Microsoft SQL Server\100\Tools\Shell\SqlStudio.bin

or possibly:

C:\Documents and Settings\[user]\Application Data\Microsoft\Microsoft SQL Server\100\Tools\Shell

----

For Sql Server Management Studio 2008 on Windows 7, to restart all your logins, delete the file:

C:\Users\%username%\AppData\Roaming\Microsoft\Microsoft SQL Server\100\Tools\Shell\SqlStudio.bin

Delete a maintenance plan after changing SQL Server 2008 name

I've seen a few posts on how to delete an older maintenance plan after you've changed the computer name for a default installation of SQL Server 2008, but none of the posts fully solved the problem. Below is what I had to do--with the caveat that you have to find your own id's:

USE msdb

DELETE 
FROM dbo.sysmaintplan_log 
WHERE subplan_id = '36F8247F-6A1E-427A-AB7D-2F6D972E32C1'

DELETE 
FROM dbo.sysmaintplan_subplans 
WHERE subplan_id = '36F8247F-6A1E-427A-AB7D-2F6D972E32C1'

DELETE 
FROM dbo.sysjobs 
WHERE job_id = '3757937A-02DB-47A6-90DA-A64AE84D6E98'

DELETE 
FROM dbo.sysmaintplan_plans 
WHERE id = 'C7C6EFAA-DA4D-4097-9F9F-FC3A7C0AF2DB'