« October 2003 | Main | January 2004 »

November 19, 2003

Permission Requests

Since the syntax of permission requests is obscure and poorly documented, here’s a list of references:

[assembly:EnvironmentPermissionAttribute(SecurityAction.RequestMinimum, Read="USERNAME")]

[assembly:FileIOPermission(SecurityAction.RequestMinimum, Unrestricted=true)]

[assembly:IsolatedStorageFilePermission(SecurityAction.RequestMinimum, UserQuota=1048576)]

[assembly:SecurityPermission(SecurityAction.RequestRefuse, UnmanagedCode=true)]

[assembly:FileIOPermission(SecurityAction.RequestOptional, Unrestricted=true)]

 

Using System.Reflection.GetConstructor() was failing (returning null) for a type with a public default constructor because declarative security in the Assembly.cs file was denying FileIOPermission. With Unrestricted=true FileIOPermission it works fine. Doesn’t seem to need MemberAccess=true on ReflectionPermission. Oddly, over 500 MemberInfo instances were returned by a call to GetMembers at the same time the GetConstructor & GetConstructors calls were returning nothing. Tested whether it mattered that the constructor was accessing the file system. It did not.

 

[assembly:ReflectionPermission(SecurityAction.RequestMinimum,MemberAccess=true)]

[assembly:FileIOPermission(SecurityAction.RequestMinimum, Unrestricted=true)]

 

November 17, 2003

Visual Studio .NET 2003 solution files with corrupted source control settings

Spent entirely too much time today figuring out why Visual Studio .NET 2003 solutions sometimes get wedged in a "some of the properties associated with the solution could not be read" state.

The solutions appear to be okay otherwise, but each time they are opened, you get the error message.

The problem is introduced when projects are added to the solution. I’ve observed it with web application projects already under Perforce source control.

The solution file (.sln) will have a SccNumberOfProjects value greater than the actual number of projects and there will be duplicates of some projects. The duplicates are typically missing the SccProjectFilePathRelativizedFromConnection# property.

To fix the problem (or at least to get rid of the error message):

1.       Adjust the SccNumberOfProjects property value to the expected number.

2.       Delete duplicate SourceCodeControl information. The usual sequence of properties is something like:

         GlobalSection(SourceCodeControl) = preSolution

         SccNumberOfProjects = 11

         SccProjectName0 = Perforce\u0020Project

         SccLocalPath0 = .

         SccProvider0 = MSSCCI:Perforce\u0020SCM

         CanCheckoutShared = true

         SolutionUniqueID = {A0C7BB98-83C3-491B-9A97-CDE906E50E22}

 

         SccProjectUniqueName1 = http://localhost/jq/h/JobQuake\u0020Help.csproj

         SccLocalPath1 = JobQuake\u0020Help

         CanCheckoutShared = true

         SccProjectFilePathRelativizedFromConnection1 = http://localhost/jq/h

 

         SccProjectUniqueName2 = http://localhost/jq/a/JobQuake\u0020Admin.csproj

         SccLocalPath2 = JobQuake\u0020Admin

         CanCheckoutShared = true

         SccProjectFilePathRelativizedFromConnection2 = http://localhost/jq/a

 

3.       Adjust the trailing indices on SccProjectUniqueName, SccLocalPath, and SccProjectFilePathRelativizedFromConnection to run from 1 to SccNumberOfProjects, inclusive.

 

November 13, 2003

Web Application Virtual Directory Binding

The .csproj.webinfo file should be in source control. It binds the folder to an IIS virtual directory. Typical contents are:

<VisualStudioUNCWeb>

    <Web URLPath = "http://localhost/csk/csk.csproj" />

</VisualStudioUNCWeb>

November 10, 2003

Lessons learned from FxCop

Add the following to Assembly.cs

[assembly:System.CLSCompliant(false)]

[assembly:System.Runtime.InteropServices.ComVisible(false)]

 

Specify an assembly KeyFile:

[assembly: AssemblyKeyFile(@"..\..\..\..\kzKey.snk")]

 

Set the projects “Wrapper Assembly Key File” property to assign strong names to automatically generated interop assemblies.