Visual Studio 2005 does not detect changes in encoding when a file is reloaded. If you have changed the encoding of a file outside of the current editor, or performed a source code control operation that changed the encoding of a file open in the editor, Visual Studio reloads the file automatically. The contents of the file might display incorrectly after it has been reloaded in the editor.

To resolve this issue

1. Close the file without saving the changes.
   
2. On the File menu, choose Open and then select File.
   
3. In the Open File dialog box, click the arrow adjacent to the Open button and click Open With.
   
4. From the list in the Open With dialog box, select the editor into which you want to open the file, such as the Binary or Resource editor. To open the file with a particular encoding, select an editor with encoding support, such as XML Editor with Encoding.
   
5. Click OK.
   
6. In the Encoding dialog box, select the correct encoding from the Encoding drop-down list.
   
7. Click OK.
   

 

1. Front Page Server Extensions for IA64 WOW64    

When using .NET Framework 1.1 to author a website on a remote IA64 computer running .NET Framework 1.1, FrontPage will not be a supported mechanism. Some basic functionality will work via the fileshare mechanism.

2. J# does not support running on native 64-bit. J# code can only run in WOW64 on 64-bit platforms.    

3. SQL Server Express is not supported on 64-bit for .NET Framework 2.0.

4. There are no performance or scalability guarantees for high-load ASP.NET applications running on .NET 1.1 in WOW64 for IA64.

5. Data breakpoints do not work with Visual Studio running on IA64 in WOW64.    

6. The Edit and Continue debugger feature does not work on 64-bit

7. In Visual Studio 2005, VC ATL exceptions:    

- Build system doesn't register dlls targeting 64-bit on wow64

- Error ""%1 is not a valid Win32 application"" when debugging default ATL Server project on 64-bit machine

- Executable to debug and URL are not prepopulated for ATL Server projects with 64-bit configs

- IE doesn't come up with .srf file specified by user when debugging 64-bit ATL Server project

- Debugger type for ATL Server 64-bit config defaults to local windows debugger instead of webservice debugger

- Debugging properties are not propagated to new configurations in a project. This means that, for example, if you start out with an ATLServer project in x86, then create a 64 bit config for it, debugging won't work without changing the debuggee to be IE.


8. There is no support for interop debugging (managed + unmanaged mixed-mode debugging) in 64-bit    

9. Some MDAs are not supported on 64-bit - examples: Reentrancy, LoaderLock, PInvokeStackImbalance

10. MMX intrinsics are not supported by the IA64 and x64 C++ compilers.

11. Inline assembly is not supported by IA64 and x64 C++ compilers.

12. Most High Level Language constructs are not supported by x64 MASM.
MASM does not support IA64, but we ship Intel's assembler (ias.exe)

13. VC++ compiler switch /ARCH:SSE is not supported by x64 and IA64 VC++ compilers.

14. The System.Diagnostics.Process.MainModule and System.Diagnostics.Process.Modules APIs will fail if running under the WOW64 on a 64bit child process.

15. 32bit and 64bit COM+ serviced components with the same GUID/CLSID cannot be registered at the same time.

16. 64-bit SDK does not include native DBGCLR. DBGCLR will be WOW64 Only.

17. 64-bit SDK does not include a native DEXPLORE.EXE. DEXPLORE.EXE will be WOW64 Only.

18. There are no bootstrapper manifest packages for x64 and IA64.  There is no 64-bit bootstrapper for ClickOnce or other applications. On any 64-bit machine that has .NET Framework installed, if you try to install a ClickOnce app, it fails with an error message “This version of the .NET Framework 2.0 is not supported on a 64-bit operating system. Contact your application vendor.”   This even happens for applications that are authored as 32-bit only and would have run in WOW64.

19. Visual Studio does not install on IA64    

VS2005 (all SKUs) will not install on IA64 (no design time support for IA64). VC will have a native IA64 command line tools installer.

20. Only Visual Studio Team System will allow building applications that target IA64    


21.P/Invoke signatures with blittable types are treated differently on 64-bit    

P/Invoke is implemented differently on 64-bit, hence there are cases where incorrect P/Invoke signatures that accidentally worked on 32-bit don't work on 64-bit.

22. Visual Studio Tools for Office (VSTO) is not supported on 64-bit.
  

 

Most existing COM components are only available for 32-bit platforms and will not run in a 64-bit process on a 64-bit platform (although they will run correctly in a 32-bit process on a 64-bit platform). VB and C# applications that reference these 32bit COM components will not run by default on a 64-bit platform because by default the application will launch as a 64-bit process.

The problem appears when a project with one or more COM references is:
1. Migrated to VS 2005 and executed on 64 bit platforms

-or-
2. Created using VS 2005 on 64 bit platforms

In VS 2005 the VB and C# compilers use the platform target property to determine if the.exe or .dll should run in 32 bit or 64 bit CPU architecture mode. The default setting for this property in Visual Studio 2005 is set to 'AnyCPU' which indicates that the application can run in either 32 and 64 bit mode, depending on the host platform. In this situation you may see an error such as "Cannot instantiate class …" when you debug or run these applications.

To resolve this issue

Set the platform target property to 'X86' for your VB or C# projects that have references to COM components.

For C# Projects:
1.    Right click the project in the solution explorer and open 'properties'
2.    Choose the Build tab
3.    Set the Platform Target property to 'X86'

For VB Projects:
1.    Right click the project in the solution explorer and open 'properties'
2.    Choose the Compile tab
3.    Press the Advanced Compile Options… button
4.    Set the Target CPU property to 'X86'

Express Edition:
The VB and C# Express products to not expose the Target property inside the development environment. You will need to carefully modify the project file using a text or XML editor.
1.    Close the project and/or solution
2.    Select Open File from the File menu
3.    Navigate to the project directory, and highlight the project file
4.    Press the Open button, the project file should open in the XML editor
5.    Locate the first <PropertyGroup> section and add the following line:
<PlatformTarget>x86</PlatformTarget>
1.    Save the project file
2.    Reopen the project and/or solution using Open Project/Solution from the File menu
3.    Continue with development, debugging, and testing

Alternatively, if the application is targeted to 64-bit platforms, you can ensure that the COM controls added to the application have 64-bit equivalents on the development and deployment computers.

 

When any product in the Visual Studio 2005 family of products is used with Windows Roaming Profiles, the first time launch message that says "Visual Studio 2005 is configuring the environment for first time use. This might take a few minutes." might appear on every session startup. This might cause unnecessary slowdowns in startup performance.

To resolve this issue

Click Tools > Options... Select "Import and Export Settings", and change the path under "Automatically save my settings to this file:" to a path that is NOT under the "My Documents" directory.

 

A reset of environment settings can be performed by clicking Tools > Import and Export Settings... and then choosing "Reset all settings". A reset of environment settings can also be performed by issuing the command "Tools.ImportAndExportSettings /reset" inside the Command Window. In either case, the fonts and colors options are not reflected until a restart of Visual Studio.

To resolve this issue

After performing a reset operation, restart Visual Studio.

1.6   DMO does not work on Windows 2000 Service Pack 4. 

C# Code Snippets are defined in XML within .snippet files. One of the possible tags in the schema is a <Shortcut></Shortcut> tag. Shortcuts can be used to quickly insert a snippet. To do so, a user simply needs to type the shortcut string and then press Tab.

Many unicode characters are allowed within shortcut strings, but non-spacing marks found in complex script languages are not recognized as valid shortcut characters. This means that some strings in complex script languages cannot be used as shortcuts. If a shortcut does contain a non-spacing mark, typing the shortcut string and hitting Tab will insert a Tab character but will not insert the snippet code.
Note: The snippet shortcut will still appear in IntelliSense.

To resolve this issue

1. Choose a Unicode shortcut name that does not contain a non-spacing mark.
2. Insert the snippet through the Snippet Picker UI instead of using shortcuts.

 

The package for Microsoft Visual J# Redistributable 2.0 appears with a warning icon in the Prerequisites dialog, which is accessed from the Publish tab in the project designer,

To resolve this issue

The warning can be safely ignored.

 

By default, applications created with VB, C# or J# Express will be set to load on "AnyCPU". These applications will load in the 64-bit CLR if one is present, but will load in the 32-bit CLR otherwise. However, there are some types of applications that will not work if they are run in the 64-bit CLR. Specifically, applications that use references to 32-bit COM components or to some versions of DirectX might not run correctly on 64-bit. Though the Platform Target can be changed from "AnyCPU" to "x86" in non-Express Edition Visual Studio Products, this option is not available in Express Editions.

To resolve this issue

1. OpenTools->Options
2. Check “Show all settings”
3. Check “Project and Solution->Show Advanced Build Configurations”
4. Open Build->Configuration Manager
5. Select the combo box under the “Platform” column for the project you want to target x86
6. Choose “”
7. Under “New Platform” select x86
8. Click OK, then Close
9. Note that the Toolbar combobox for Platform Configuration now lists both x86 and AnyCPU and has x86 selected
10. Building, running debugging will now build x86-only binaries. You can switch back to the AnyCPU configuration to change this.

 

In certain cases, the message "Microsoft C# 2005 IntelliSense has encountered a problem. We are sorry for the inconvenience" can appear while performing various actions in the editor. The root cause in most cases is that there is a failure with retrieving the source data.

Some examples of actions that could trigger this error dialog include:
- Renaming an external alias
- Performing a find all references in a web project with no 'runat="server"' attribute

This is a non-fatal dialog. Clicking the send report button will allow a user to safely continue working as expected and no data will be lost.

To resolve this issue

There are two possible options to turn off display of all non-fatal error messages from the C# language service. To do this, modify the registry under the registry path:

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\CSharp\Options\Editor]

(1) "Watson_ReportExceptions"=dword:00000001
Adding the following registry key with the specified value will disable error reporting completely.

Note: Using this registry key and turning off all non-fatal error messages from the C# language service can potentially prevent gathering feedback on scenarios not related to this failure.

(2) "Watson_DeferSendingUntilLater"=dword:00000000
Adding the following registry key with the specified value will turn of the display of the error message but will continue to send feedback to Microsoft. The IDE will be unresponsive for a brief period as information is collected to send.

 

Using User-Defined Types as Settings might cause problems if the assembly in which the UDT resides is updated while the consuming project is open. If this scenario is required, you can workaround the problem by making the UDT assembly use incremental version semantics.

To resolve this issue

If the User Defined Type that is being used as a setting resides in a class library, incrementally version the library to mitigate the problem. If the User Defined Type resides in an EXE, the IDE must be closed and restarted for changes to the UDT to take affect.

 

My.Forms will not be available in a User Control project

 

If you have the following code running on a remote computer, then attach to the running code via remote debugging, and break as execution is inside the call to Sleep(), you will be unable to evaluate members of the variable c.

c = New c1     'assume c1 is a valid class
While True
Threading.Thread.Sleep(1000)
End While

To resolve this issue

Step out of the Sleep(), you will then be able to evaluate objects normally.

 

On Windows 98, you cannot pass a structure to a variant property in an ActiveX EXE object. The problem is on a clean Windows 9X machine, the System DLL rpcrt4.dll was not registered by default, so the operating system is missing the registration key [HKEY_CLASSES_ROOT\CLSID\{B5866878-BD99-11D0-B04B-00C04FD91550}]. The invocation fails because of this missing registration.

To resolve this issue

Go to C:\Windows\System and manually invoke RegSvr32.exe rpcrt4.dll.

 

Pasting the code below in a console application will cause it to hang.

Class C1(Of U As U)    'the cyclic constraints here cause the later problem
End Class

Partial Class C1(Of U)
Dim x As New U        'Issue - this causes infinite looping and the memory usage keeps increasing until memory is no longer available

End Class

To resolve this issue

Remove the cyclic constraint.

 

Parameters to StartupNextInstanceEvent handler will not contain the command line arguments of the second instance of the application if application is started using ClickOnce. You must use the My.Application.Deployment.ActivationUri property to get the command line arguments.

To resolve this issue

Use the ASP runtime classes to get the command-line arguments, as follows:

Imports System.Web

Dim commandLineArgs as NameValueCollection = _
HttpUtility.ParseQuery(My.Application.Deployment.ActivationUri)

 

<Assembly: InternalsVisibleTo("Foo.Dll, PublicKeyToken=a29c01bbd4e39ac5")>

This attribute exposes Friend types to other assemblies. This attribute is not supported by the VB compiler.

Some unit testing technologies that rely on this attribute for testing private types will not work as expected.

To resolve this issue

There is no known resolution.

 

The package for Microsoft Visual J# Redistributable 2.0 appears with a warning icon in the Prerequisites dialog, which is accessed from the Publish tab in the project designer,

To resolve this issue

There is no known resolution.

 

1) Create a new Console Application with the following code:

    My.Application.Log.DefaultFileLogWriter.CustomLocation = "D:\temp"
    My.Application.Log.WriteEntry("Foo")

2) Run the application

RESULTS:
Log file is created in D:\temp, but the directory D:\Documents and Settings\<username>\Application Data\Microsoft\WindowsApplication1\1.0.0.0 is also created if it does not exist. In the case that the user does not have permission to do this, an Exception is thrown. This is likely to occur when using a class library in a Web application, because the ASP.NET process does not have write permission to any Application Data directory by default.

To resolve this issue

1) Remove the default FileLogTraceListener via app.config, and Reconfigure My.Application.Log to use a different TraceListener.
2) Listen to Unhandled Exception event and simply continue when we get this one
3) Try/catch every logging call (or at least the ones that could conceivably be the first to execute).

 

Using User-Defined Types as Settings might cause problems if the assembly in which the UDT resides is updated while the consuming project is open. If this scenario is required, you can workaround the problem by making the UDT assembly use incremental version semantics.

To resolve this issue

If the User Defined Type that is being used as a setting resides in a class library, incrementally version the library to mitigate the problem. If the User Defined Type resides in an EXE, the IDE must be closed and restarted for changes to the UDT to take affect.

 

Latebound calls on Windows 2000 or Windows 9x passing a Long (VT_I8) will fail. Windows XP is the only supported platform for VT_I8 through OLE automation.

To resolve this issue

Use integer rather than long.

 

Using User-Defined Types as Settings might cause problems if the assembly in which the UDT resides is updated while the consuming project is open. If this scenario is required, you can workaround the problem by making the UDT assembly use incremental version semantics.

To resolve this issue

If the User Defined Type that is being used as a setting resides in a class library, incrementally version the library to mitigate the problem. If the User Defined Type resides in an EXE, the IDE must be closed and restarted for changes to the UDT to take affect.

 

Using User-Defined Types as Settings might cause problems if the assembly in which the UDT resides is updated while the consuming project is open. If this scenario is required, you can workaround the problem by making the UDT assembly use incremental version semantics.

To resolve this issue

If the User Defined Type that is being used as a setting resides in a class library, incrementally version the library to mitigate the problem. If the User Defined Type resides in an EXE, the IDE must be closed and restarted for changes to the UDT to take affect.

 

The AuthorizationStoreRoleProvider depends on Authorization Manager. Not all error messages returned from AuthorizationManager indicate the root cause of a problem. Listed below are error messages that are known to be either incorrect or vague.

"COMException (0x8007052b): Unable to update the password. The value provided as the current password is incorrect."
This error is really an access denied error. If all of the following conditions are met, this error can occur: ASP.NET is deployed on IIS 5.0, Windows XP IIS 5.1, or in IIS 5.0 isolation mode on Windows Server 2003, the application is configured to use Integrated Windows Authentication, and the policy file is located inside of the directory structure of the current ASP.NET application. If ASP.NET is running as a local computer account and attempts to access a policy store in a remote AD or ADAM instance this error can also occur.

"More data is available"
This error really means that the policy store could not be found. If the connection string points at an ADAM instance, but the connection string references an ADAM partition that does not exist, this error can occur. For example, in the following connection string “LDAP://localhost:4000/Cn=storename, DC=Partition1”, if Partition1 does not exist in the ADAM instance, this error will occur.

"The specified server cannot perform the requested operation"
This error really means that the specified server could not be found. If the connection string points at a non-existent server, or uses a port number that AD or ADAM are not listening on, this error can occur.

"ArgumentException: The parameter is incorrect"
This error message really indicates that an LDAP query group in Authorization Manager used to determine if a user is in a role is invalid.

To resolve this issue

For each error condition listed above, review the possible causes. If an application's configuration matches one of the possible causes, change or fix the application's configuration based on the information listed above.

 

ASP.NET 2.0 integrates with SQL Server Express 2005 to provide automatic creation of the database required by many of ASP.NET 2.0's new application services. This functionality relies on SQL Server Express' support for spawning server processes that run with the identity of either the interactive user or the identity of the worker process hosting ASP.NET. In un-trusted environments such as a shared hosting server, the ability to spawn SQL Server worker processes should not be enabled due to the potential for unintentionally sharing data between ASP.NET applications.

To resolve this issue

If you are installing SQL Server Express using the standalone installer, you can use the advanced setup options to explicitly disable support for user instancing.

Alternatively you can manually disable user instancing for an existing SQL Server Express installation as follows:
1. While logged in as a local box administrator, open a command window by running cmd.exe
2. If osql.exe is not available from any directories listed in the PATH environment variable, change directories to the SQL Server Express directory that contains osql.exe.
3. Connect to the parent instance of SQL Server: osql –E –S .\sqlexpress
4. Issue the following SQL commands:
exec sp_configure 'show advanced option', '1'
go
reconfigure with override
go
exec sp_configure 'user instances enabled', 0
     go
reconfigure with override
go

 

In previous versions of ASP.NET, persistent forms authentication cookies had a hardcoded lifetime of 50 years. In ASP.NET 2.0 persistent form authentication cookies have their expiration date set to the current date time plus the value of the "timeout" attribute from configuration. By default this means persistent cookies will have a lifetime of 30 minutes. If you want a longer lifetime you will need to increase the value of the "timeout" attribute. In ASP.NET 2.0 this means that forms authentication tickets stored in both session-based and persistent cookies will use the new timeout value

To resolve this issue

If different timeout values are desired for persistent cookies, a developer can get a reference to the forms authentication cookie after initially setting the cookie with a method like FormsAuthentication.SetAuthCookie. A developer can then get a reference to the cookie with a call to: Response.Cookies[FormsAuthentication.FormsCookieName]. On the resultant HttpCookie a developer can then set the Expires property to a different value.

 

The DeleteRole method on the provider incorrectly throws an exception stating "Element not found" if an attempt is made to delete a non-existent role. The provider should be returning false instead. Also, if an attempt is made to delete a role that has existing users in it, the provider will return false instead of throwing an exception.

To resolve this issue

1. Wrap all calls to the provider's DeleteRole method inside of a try-catch block. This will ensure that any future fixes that re-enable exceptions when deleting populated roles will not impact existing code.
2. Check to see if the role exists prior to attempting to delete the role.

 

The default property serialization mechanism for the ASP.NET Profile feature is Xml serialization. If the ASP.NET process identity is something other than ASPNET (on IIS 5.0 and IIS 5.1) or NETWORK SERVICE (for IIS 6), then the Xml serialization process will fail with an exception stating "InvalidOperationException: Unable to generate a temporary class." The same problem will occur if using application impersonation. These exceptions occur because the XmlSerializer writes temporary class files into the %windir%\temp directory. By default this directory only grants " List Folder/Read Data" permissions to the default ASP.NET accounts. Non-default ASP.NET accounts are able to write temporary files into this directory, but do not have the necessary privilege to subsequently find the temporary classes for use by the XmlSerializer.

To resolve this issue

For secure environments, developers should use a different serialization mechanism - either binary serialization or string serialization. For applications where the potential for accidentally sharing temporary class files across applications is not high, the worker process or application impersonation identity can be granted the "List Folder/Read Data" privilege on the %windir%\temp directory.

 

SSE should only be used in development environments with ASP.NET Sql Server based session state because there is no Sql Server Agent service installed with SSE. As a result the session state cleanup job never runs and session state data will accumulate in the database. You can manually cleanup expired sessions by connecting to SSE and running the following command: "EXECUTE DeleteExpiredSessions".

To resolve this issue

Use one of the standard versions of SQL Server 2005 for production applications.

 

Authorization Manager does not allow the "/" character in application names. In the absence of applicationName being set in configuration, the AuthorizationStoreRoleProvider follows the same logic used by other ASP.NET providers to determine a default value for applicationName. When running within ASP.NET, this results in a value that starts with the "/" character.

To resolve this issue

Always set the applicationName attribute in configuration when using the AuthorizationStoreRoleProvider within an ASP.NET application.

 

In previous versions of the .NET Framework, System.Net's DNS added timeout logic to the Dns type in order to circumvent the lengthy native timeout. Without an accurate DNS timeout, it is not possible to set accurate timeouts for other web requests. However, to implement this timeout, the DNS resolve is offloaded to a separate thread. If the thread pool level is low, the DNS resolve may wait for an available thread until it times out, resulting in an exception being thrown. To avoid this exception, the DNS timeout logic has been removed.

To resolve this issue

There is no known resolution.

 

Due to changes in how query notifications work with SQL Server 2005, developers must call the Start method on SqlDependency at least once prior to using SqlCacheDependency. A logical place to call Start is inside a web application's Application_Start method located in global.asax:

void Application_Start(object sender, EventArgs e)
{
System.Data.SqlClient.SqlDependency.Start("connection string");
}

The connection string must be the same one that will be used when issuing commands for use with SqlCacheDependency.

 

In previous versions of the .NET Framework, calls to WebClient.UploadValues() would add a CRLF to the uploaded content resulting in server application failures. The CRLF characters violate the application/x-www-form-urlencoded content type encoding scheme, as described in the HTML 4.01 specification. The CRLF is no longer added.

To resolve this issue

Use WebClient.UploadData() to add the CRLF and recompile your application or fix the server application to not expect the CRLF character.

 

UriBuilder is a type that allows building a Uri instance piece by piece. In previous .NET Framework versions, the Query properties and Fragment properties could not be set at the same time.  This error has been fixed in version 2.0. Query and Fragment properties are now set without having any fields inadvertently cleared. Applications that have worked around the previous behavior may need to adjust their logic to avoid erroneous behavior.

To resolve this issue

There is no known resolution.

 

The permissions required to apply the settings present in the System.Net element of an application configuration file are changed from previous .NET Framework versions. The permissions required to apply values from the configuration file are now the same as those required by the associated property when changing the setting in code.

To resolve this issue

There is no known resolution.

 

If an application issues a FTP request to a server, and then issues another FTP request with SSL enabled to the same server and path, the second request will fail. A file not found exception will be thrown. However, if the second request is not to the same path, the request will succeed.

 

This new demand prevents applications running in partial trust from discovering network proxy addresses. Partially trusted applications using ServicePoint.Address API may get a SecurityException if the address points to a proxy server.

To resolve this issue

Use HttpWebRequest.Address

 

Prior to .NET Framework version 2.0, applications could register a component to handle FTP requests using System.Net's extensible pluggable protocol framework. Components for handling different web requests are registered by associating the component with a specific URI prefix. Any web request that matches that prefix is then handled by that component. In  .NET Framework 2.0, System.Net now supports an FtpWebRequest component that is registered by default for the “ftp:” prefix. Any applications that are registering for this prefix (prior to this release) could now be broken because the prefix (FTP) is already taken.

To resolve this issue

Update the application configuration file to remove the default FTP protocol component prior to registering your own FTP component:
<system.net>
<webRequestModules>
<remove prefix = “ftp:” />
</webRequestModules>
</system.net>

 

In version 1.1 of the .NET Framework, specifying an empty System.Net element in the machine.config file, GlobalProxySelection.Select returns an empty web proxy instance indicating that no proxy is to be used. In version 2.0, the new default is that the system proxy settings (same as what is specified in Internet Explorer) will be used in this case.

To resolve this issue

Modify the machine.config file to disable the default proxy as shown below.
<system.net>
<defaultProxy enabled=”false” />
</system.net>

 

In previous .NET Framework versions, if you created a Uri instance using an IPv6 address, the scope ID is always included with the host address. The scope ID refers to the index of a local network adapter, and has no meaning for a remote host. The scope ID also uses a '%' character in its syntax, which conflicts with the Uri escaping format of '%hh'. Including the scope ID in the host breaks System.Uri's ability to interoperate with other URI parsers and resolvers. In version 2.0, System.Uri no longer includes the scope ID with an IPv6 host in a Uri instance. System.Uri has also added a new property, DnsSafeHost, which will return the scope ID with an IPv6 host address.

To resolve this issue

Use Uri.DnsSafeHost which will return the scope ID with an IPv6 host address

 

If a cluster is specified as a remote proxy in configuration by setting the DistributedTransactionManagerName to a cluster, a TransactionException may be thrown during cluster failover.

To resolve this issue

To specify a cluster as a remote proxy, use the Component Services MMC to configure MSDTC to use the cluster as the remote MSDTC.

 

Attempting to get the DistributedIdentifier on a Transaction while the transaction is promoting may cause a NullReferenceException to be thrown.

To resolve this issue

There are two ways to work around this issue.

Ensure that access to the transaction is synchronized

-or-

Ensure that the transaction has promoted before checking the DistributedIdentifier property.

 

When adding a Web Reference in Visual Studio 2005, the URL of the service is automatically picked up from the AppSettings section in the configuration file. If the web service has multiple endpoints with different URLs, multiple proxy types will be generated but they will all use the same URL value taken from the configuration file.

To resolve this issue

There are two possibilities:
1. Edit the wsdl document and break out each service into a separate document

-or-

2. Edit the configuration file to add a key for each Web service and then read the values out in your code using System.Configuration.ConfigurationSettings.AppSettings. Set the URL property on your proxy instances using these values.

 

When importing a schema that contains the nullable="true" attribute for an ASP.NET Web Service the generated proxy will contain Nullable<T> types, whereas previously the attribute was ignored. This change may cause design time or runtime breaks in applications.

To resolve this issue

Possible workarounds are to avoid regenerating your proxy types, to recompile your code using the new Nullable<T> pattern, or to change the schema to not use the nullable="true" attribute.

 

Setting the Proxy property to null on a web service proxy instance should force the request to bypass any web proxy server settings and go directly to the server. However, this functionality does not currently work. The null value will be ignored and any configured web proxy server settings will be used instead.

To resolve this issue

You can set the Proxy property on the underlying WebRequest directly by deriving from the proxy type and overriding the GetWebRequest method:

protected override WebRequest GetWebRequest(Uri uri)
{
WebRequest req = base.GetWebRequest(uri);
req.Proxy = this.proxy;
return req;
}

 

When exchanging data between an application running on one version of the .NET Framework and an application running on another version (using .NET Remoting or Runtime Serialization), exceptions may be encountered while serializing or deserializing certain Framework types. These exceptions indicate that these types are incompatible across the different Framework versions – that is, it is impossible to send them from one version of the Framework to another.

.NET Framework 2.0 includes a technology called Version Tolerant Serialization that eliminates this problem. However, previous versions of the Framework still face this issue. Thus, a patch will be made available that adds some Version Tolerant Serialization capabilities to .NET Framework 1.1. This patch will require Service Pack 1. After installing the patch, an application running on the patched Framework will be able to communicate with an application running on .NET Framework 2.0 without encountering this versioning issue. There are no plans to provide such a patch for .NET Framework 1.0.

It is worth noting that Version Tolerant Serialization only addresses versioning when using Binary Serialization, either directly or through .NET Remoting. When using SOAP serialization (either directly through the SoapFormatter class or through .NET Remoting) across different versions of the Framework, the versioning issues discussed above may still be encountered.

To resolve this issue

To obtain this patch, please see the following Knowledge Base article: http://support.microsoft.com/?kbid=907262.

 

Specifying a specific trace listener for System.Transactions tracing in the configuration is not supported in partial trust and will cause an exception to be thrown.

To resolve this issue

The default trace listener is supported in partial trust so if no listener is specified in configuration, the traces will be caught by the default listener and printed to debug.outputstring. These traces can be viewed in partial trust by using DBMon.exe.

 

NET Framework 2.0 changes the way dates and times are written to and read from XML. This change mostly affects the following scenarios:
- Using times with an unspecified time zone or times in the UTC time zone.
- Interoperability scenarios with 3rd-party software that writes out time values to XML without specifying a time zone or specifying the UTC time zone.

The changes may cause certain date and time calculations and comparisons to become incorrect. In these cases, it may be necessary to revert to the earlier date/time behavior.

To resolve this issue

To revert to the earlier date/time behavior, apply the following configuration change:

<system.xml.serialization>
<dateTimeSerialization mode="Local" />
</system.xml.serialization>

 

The ASP.NET automatic MDF creation process for SQL Server providers using SQL Server Express and IIS only works when IIS is running either as the local ASPNET computer account, or as NT AUTHORITY\NETWORK SERVICE. The automatic creation process also works when a developer is interactively developing using Cassini (i.e. file based webs). However, when developing against IIS using either a different local computer account, or a domain user account, the automatic database creation process will fail because these accounts do not have a Windows user profile available on the web server.

To resolve this issue

There is no workaround for this issue. Automatic database creation with SSE for IIS-based websites will only work for the ASPNET and NETWORK SERVICE accounts.

 

ASP.NET providers that use SQL Server are constrained to the level of Unicode surrogate support provided by SQL Server 7.0 and Sql Server 2000. SQL Server 7.0 and 2000 store and retrieve surrogate pairs losslessly. However, there is no linguistic comparison for surrogates. Surrogate characters are ignored during comparison operations and during uniqueness checks when using these versions of SQL Server. For example this means the SqlMembershipProvider will consider two usernames that only include surrogate characters to be identical. This behavior will lead to a uniqueness constraint violation if an attempt is made to create a second user with a username that differs from an existing user only in surrogate characters.

To resolve this issue

There is no known resolution.

 

Types that inherit from WebRequest inherit a PreAuthenticate property. This property is used to enable sending authentication information along with the request without waiting for a challenge from the server. FileWebRequest does not support preauthentcation, so its PreAuthenticate property should always return false. In previous .NET Framework versions, if the PreAuthenticate property was set to true by an application, it would return true when its value was later queried. This is no longer the case. FileWebRequest's PreAuthenticate property will always return false.

To resolve this issue

Users should not use the PreAuthenticate property on FileWebRequest.

 

The .NET Remoting technology supports both binary and SOAP serialization – that is, Remoting messages may be represented in a Microsoft-specific binary format or as SOAP XML. However, generic types (which are a new feature in .NET Framework 2.0) may only be used with binary serialization. The usage of generics with SOAP serialization is not supported, neither through .NET Remoting nor by using the SoapFormatter class directly.

To resolve this issue

There is no known resolution.

 

In certain cases, when performing a refactoring command in a C# web site that contains no build errors, the user may get a warning indicating that the project or one of its dependencies does not currently build and that references may not be updated.
This dialog can be safely ignored by clicking on the Continue or Preview buttons. The refactoring will succeed and all references will be updated.

The following are examples of common project configurations in which this warning will be shown:
- Web projects migrated from previous versions of Visual Studio, which contain a global.asax file in the web directory and a global.asax.cs file in the App_Code directory.
- Web projects in which web pages reference web user controls which in turn reference types declared in the App_Code directory.

To resolve this issue

There is no known resolution.  However, the warning can be safely ignored.

 

C# Code Snippets are defined in XML within .snippet files. One of the possible tags in the schema is a <Shortcut></Shortcut> tag. Shortcuts can be used to quickly insert a snippet. To do so, a user simply needs to type the shortcut string and then press Tab.

Many unicode characters are allowed within shortcut strings, but non-spacing marks are not allowed. This means that some strings in some languages cannot be used as shortcuts. If a shortcut does contain a non-spacing mark, typing the shortcut string and pressing Tab will insert a Tab character but will not insert the snippet code.

To resolve this issue

1. Choose a Unicode shortcut name that does not contain a non-spacing mark.
2. Insert the snippet through the Snippet Picker UI instead of using shortcuts.

 

In certain cases, when performing a refactoring command in a C# web site that contains no build errors, the user may get a message indicating that the project or one of its dependencies does not currently build and that references may not be updated.
This dialog can be safely ignored by clicking on the Continue or Preview buttons. The refactoring will succeed and all references will be updated.

The following are examples of common project configurations in which this warning will be shown:
- Web projects migrated from previous versions of Visual Studio, which contain a global.asax file in the web directory and a global.asax.cs file in the App_Code directory.
- Web projects in which web pages reference web user controls which in turn reference types declared in the App_Code directory.

To resolve this issue

There is no known resolution.  However, the warning can be safely ignored.

 

If you open an FTP web site and add a data file (MDB or MDF) to the App_Data directory, then open the Server Explorer window and expand the connection to the data file
under the Data Connections node, the IDE can crash or hang, and you might lose unsaved data.

To resolve this issue

Develop the web site from a local file location using a file system or IIS web site, and use the Copy Web Site command to transfer files to and from the FTP location.

 

Using User-Defined Types as Settings might cause problems if the assembly in which the UDT resides is updated while the consuming project is open. If this scenario is required, you can workaround the problem by making the UDT assembly use incremental version semantics.

To resolve this issue

If the User Defined Type that is being used as a setting resides in a class library, incrementally version the library to mitigate the problem. If the User Defined Type resides in an EXE, the IDE must be closed and restarted for changes to the UDT to take affect.