If you copy a .net application to a network share and try to run it, you will be default get a unhelpful error message.

"... has encountered a problem and needs to close.  We are sorry for the inconvenience."

There are at least 2 ways around this:

1. You can use the .NET Framework configuration tool (Mscorcfg.msc) to change the security policy.

For .net 10, 1.1 see: http://support.microsoft.com/kb/832742

For .net 2.0: This is only installed with the SDK, so you'll likely need to use CasPol.exe below.

The easiest way to modify your security policy is by using the Microsoft .NET Framework Configuration utility from the control panel. You can also run this tool from the command line by running mscorcfg.msc.

1. Expand the Runtime Security Policy folder
2. Expand the Machine policy level
3. Expand the Code Groups folder

To modify the polcy to trust a specific strong name:

1. Right click on All_Code, and select New
2. Create a new code group for your strong name, and hit next
3. Select a strong name membership condition from the drop down box
4. Hit the import button, and select your assembly. The configuration tool will import your public key. If you want to trust everything you sign with this key, leave the name and version boxes unchecked
5. Select the FullTrust permission set

To modify the policy to allow full trust for all Intranet assemblies:

1. Expand the All_Code code group
2. Right click the LocalIntranet_Zone code group, and select properties
3. Switch to the Permission Set tab, and select FullTrust

2. On the clinet pc you can give full trust access to the whole share which allows running any .net apps frim that share (or just an individual file if you wish) as follows:

CasPol.exe -m -ag 1.2 -url file://storage/files/* FullTrust

See: http://blogs.gotdotnet.com/shawnfa/archive/2004/12/30/344554.aspx

Although there is a relative Reference HintPath in the .csproj file, when you move a solution to a different machine, the hint path may not be correct for that machine.  An easy way to get around this problem is to just ensure that your needed assembly is in the Public Assemblies folder: Program Files\Microsoft Visual Studio .NET\Common7\IDE\Public Assemblies.  Of course this should really only be done when you don't make any changes to the referenced assembly, such as a 3rd party dll.

A good summary: http://blogs.msdn.com/manishagarwal/archive/2005/09/28/474769.aspx

From: http://msdn2.microsoft.com/en-us/library/8y13ka7c(VS.80).aspx

When the project system finds an assembly reference, it resolves the reference by looking in the following locations, in the following order:

1. The project directory. The project directory files appear in Solution Explorer when Show All Files is not in effect.
2. Directories specified in this dialog box.
3. Directories displaying files in the Add Reference Dialog Box.
4. The project's obj directory. (Any assemblies created as a result of adding a COM reference to your project are added to the project's obj directory.)

From: http://msdn2.microsoft.com/en-us/library/wkze6zky(VS.80).aspx

To display an assembly in the Add Reference dialog box

* Move or copy the assembly to one of the following locations:

o The current project directory (you can find these assemblies using the Browse tab).
o Other project directories within the same solution (you can find these assemblies using the Projects tab).
o The Public Assemblies folder: Program Files\Microsoft Visual Studio .NET\Common7\IDE\Public Assemblies; (you can find these assemblies on the .NET tab).

* Set a reference path to the directory containing the assembly using the Reference Paths Dialog Box (Visual Basic) or the Reference Paths Page, Project Designer (C#, J#).
* Set a registry key that specifies the location of assemblies to display:

Add one of the following registry keys, where <AssemblyLocation> is the directory of the assemblies that you want to appear in the Add Reference dialog box, for example, C:\MyAssemblies\.

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework\<version>\AssemblyFoldersEx\MyAssemblies]@="<AssemblyLocation>"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\<version>\AssemblyFoldersEx\MyAssemblies]@="<AssemblyLocation>"

THIS WAY HAS WORKED WELL FOR ME:

The easiest way I have found to immediatley shrink the log file is to detach the database, rename the .LDF file then reattach the .MDF file. In SQL Server 2005 you'll need to remove the missing .LDF file from the list before attaching, and one will be created for you.

I DID NOT GET THIS ROUTINE BELOW TO WORK WITH SQL SERVER 2005:

From the April 2001 edition of SQL Server Magazine:

Shrinking Log Files Immediately

You can use the DBCC Shrinkfile statement in SQL Server 7.0 to shrink the size of a specified data file or log file for a related database. But SQL Server professionals often ask me why the DBCC Shrinkfile command doesn't shrink the size of their transaction logs immediately and how to make their transaction logs smaller.

SQL Server 7.0 doesn't immediately shrink log files when you issue the DBCC Shrinkfile command. The DBCC Shrinkfile operation occurs only at checkpoints or transaction log backups. SQL Server segments each physical log file internally into a number of virtual log files (VLFs), which make up the transaction log. SQL Server marks the VLFs as truncateable either after SQL Server has backed them up or at checkpoints. At any given time, you might have VLFs with free or reusable space at the beginning, middle, and end of the log. Only when the VLFs that SQL Server marked as truncateable are at the end of the log file can the DBCC Shrinkfile operation remove the VLFs and shrink the log file. Because SQL Server can shrink a log file only to a virtual-log-file boundary, you can't shrink a log file to a size smaller than the size of a virtual log file—even if you aren't using the log file. (For more information about virtual log files, see SQL Server Books Online—BOL.)

Listing 1 shows a script that shrinks the log file immediately after you stop running the script. The script first marks a shrinkpoint, which tells the DBCC Shrinkfile (or the DBCC Shrinkdatabase) command where to shrink the log file to. The script then forces truncateable VLFs to the end of the log file and issues a BACKUP command to truncate the log. In my experience, you need to run the script for 3 to 4 minutes before stopping it manually.

—Simon Su  yqsu@microsoft.com

Listing 1: Script to Shrink a Log File

/* Run "SELECT fileid, name,filename FROM <db_name>..sysfiles" to get
the fileid you want to shrink. */

USE <db_name>
GO
DBCC shrinkfile(<fileid>,notruncate)
DBCC shrinkfile(<fileid>,truncateonly)
CREATE TABLE t1 (char1 char(4000))
GO
DECLARE @i int
SELECT @i = 0
WHILE (1 = 1)
BEGIN
WHILE (@i < 100)
BEGIN
INSERT INTO t1 values ('a')
SELECT @i = @i +1
END
TRUNCATE TABLE t1
backup log <db_name> with truncate_only
END
GO

From microsoft.com:

"Beginning in Exchange 2007 Beta 2 and Outlook 2007 Beta 2, CDO 1.2.1 will no longer be provided as a part of the install of the product. As a result, there is functionality missing that many applications depend upon. CDO 1.2.1 is a package providing access to Outlook-compatible objects through a COM-based API."

You can download Collaboration Data Objects, version 1.2.1 from microsoft here.

Just as a note, CDO was included as an optional accessory starting with Outlook 2000-ish.

EXEC sp_rename 'tablename.oldindexname, tablename.newindexname', 'INDEX'

Don't forget the tablenames.