Going through the upgrade process from VS.Net 2003 to 2005.  Receiving the
following error (which I see reported by others):

Use command line option '/keyfile' or appropriate project settings instead
of 'AssemblyKeyFile'

For my purposes, strong names in released apps is required as the assemblies
are run from a remote machine by the client.

I am looking for a sanity check that I am approaching this the correct way
in VS 2005.  Formerly, I had the following code in a linked assembly infor
file for all my projects:

#if !DEBUG
    [assembly: AssemblyDelaySign(true)]
    [assembly: AssemblyKeyFile(@"..\..\..\ESD_PUBLIC.SNK")]
#else
    [assembly: AssemblyDelaySign(false)]
    [assembly: AssemblyKeyFile("")]
#endif

so that when compiling in debug mode (during development) I did not sign at
all.  Then when cut for release, Iwoudl delay sign as a manual step before
copying to the deployment location.

In VS 2005, it appears to me that I know longer have the ability to
conditionally sign the assemblies.  If that is wrong, please jump in right
here...!!!!

Otherwise, as I see, I must use the Project Properties (signing screen) at
compile time to overcome the error received during the relase mode compile. 
But than then causes a different problem when doing the debug mode compile,
as it appears the project properties overrule the attribute settings in the
assembly info file. 

That leaves me believing I no longer can conditionally sign, and I should
just go ahead and specify my pubpriv.snk file in the signing screen, and
disable delayed signing.  On the upside, my deployment reduces one step (not
needing to manually sign).

Previously I conditionally signed so that I would not accidently place
incomplete/unfinshed code into the production area...like a programmer would
ever do that!!!

Other than having to be careful not to place signed DEBUG code into the
production area, is there something else I should be on the watch for???  So
how am I doing thus far....???  Am I about to screw myself up and not yet see
it coming?!?!?

And I am open to suggestions, too.

Thank you in advance.

Conditionally signing of assemblies is still possible, even when specifying
signing behaviour via the project properties.  However, the UI does not
support the full flexibility required for this, so you'll need to do a bit
of manual editing of the build properties.  Try this...

1.  Remove all assembly-level attributes previously used to specify signing
behaviour.
2.  Specify your preferred signing behaviour for release builds using the
project properties editor then save your project.
3.  In the solution explorer within VStudio, right-click the node for your
project, then select "Unload Project" from the context menu.
4.  Once the project is unloaded, right-click the project node again, and
select the "Edit <your project>.csproj" item from the context menu.
5.  Manually edit the csproj file to move the SignAssembly and
AssemblyOriginatorKeyFile nodes from the default property group to the
release property group.
6.  Save the file then reload the project from the project context menu.


Personally, I would be quite concerned about deploying signed assemblies
when most (or all?) testing was performed on their unsigned counterparts.
Is there some particular reason you are avoiding use of delay signing for
your debug assemblies?  If you are concerned about the risks exposed by
verification skip entries, you might want to consider using the new test key
signing functionality available in fx 2.0.  (See
http://msdn.microsoft.com/msdnmag/issues/06/07/CLRInsideOut/default.aspx for
an overview and http://blogs.msdn.com/shawnfa/archive/2005/10/24/484170.aspx
for more details.)

Exception using SmtpMail.Send method
The type initializer for "HeaderEncoding" threw an exception
Visual Studio .NET 2005 using Web Application Project
Method.property string
question about sending email