Saturday, March 12, 2011

Free Video Training: ASP.NET MVC 3 Features

Free Video Training: ASP.NET MVC 3 Features

Free Video Training: ASP.NET MVC 3 Features

Posted: 09 Mar 2011 11:44 PM PST

A few weeks ago I blogged about a great ASP.NET MVC 3 video training course from Pluralsight that was made available for free for 48 hours for people to watch.  The feedback from the people that had a chance to watch it was really fantastic.  We also received feedback from people who really wanted to watch it – but unfortunately weren't able to within the 48 hour window. The good news is that we've worked with Pluralsight to make the course available for free again until March 18th.  You can watch any of the course modules for free, through March 18th, on the www.asp.net/mvc website here : The 6 videos in this course are a total of 3 hours and 17 minutes long, and provide a nice overview of the new features introduced with ASP...(read more)

DevConnections Conference

Posted: 09 Mar 2011 09:08 PM PST

The excellent DevConnections conference will be held in Florida later this month (March 27th to 30th).  DevConnections features multiple concurrent tracks – including ASP.NET Connections, Silverlight Connections, Visual Studio Connections, SQL Server Connections, and SharePoint Connections. I'll be doing a keynote on the first day, and there will be dozens of fantastic talks that week by some of the best presenters in the .NET community.  You can learn more about the conference here . I highly recommend the conference – and hope to meet up with some of you there! Scott P.S. Use the discount code "DevCon1" to save $200 when registering. Read More......(read more)

SQL Script Executer

Posted: 11 Mar 2011 10:28 AM PST

SQL Executer makes it easy to deploy, execute multiple scripts on SQL Server as you could do in VS 2008. In Visual Studio 2008's Database Project, one had an option to select multiple sql files and Run them on choosen DB. Visual Studio 2010, doesn't come with this functionality.

Proposed Workaround for Assembly Signing Issue with VS2010 SP1

Posted: 11 Mar 2011 07:56 PM PST

Hi, my name is Amit Mohindra and I'm Program Manager with the MS Visual C++ team.

We are very sorry for the inconvenience caused by this assembly signing issue. We recognize that this change in SP1 has introduced an unintentional breaking change. This is indeed a bug in VS2010 SP1.

I will start by giving you a little bit of background into what the issue was in VS2010 RTM, how our change in SP1 broke your projects and then finally the workaround you could apply to unblock yourselves.

 

  1. VS2010 RTM
    1. Assemblies built using C++ projects were not getting signed at all.
      1. This was happening since mt.exe would invalidate the signature performed by the preceding Link step (which signs the binary). This is expected behavior.
      2. To counter the invalidation the build process runs and additional "LinkEmbedManifest" step to re-sign the assembly after mt.exe is done embedding the manifest.
      3. However, in VS2010 RTM step 1.a.B was being skipped. Thus, the assemblies were not getting signed.
    2. So we recommended a workaround to run "sn.exe –R <assembly> <KeyFile>" (e.g. sn -R debug\CLRConsole.exe C:\mykey.snk)  as part of the custom build step and to sign the assembly.
  2. VS2010 Sp1 (fix that broke you)
    1. The main reason why "LinkEmbedManifest" step was getting skipped in VS2010 RTM was that during the build process our decision logic to trigger this step did not have enough information. The decision logic required evaluated values for "Key File" and "Delay Sign" (properties on the Linker). These values were stored as "Item Definition Group"  (IDG) in the project file and IDG's are evaluated at a later stage than the decision point and thus were unavailable.
    2. To fix the issue we made "Key File" and "Delay Sign" MSBuild properties (<PropertyGroups>) instead and since MSBuild properties are evaluated early on we would now be able to decide whether to run "LinkEmbedManifest" step or not. With this change we would have eliminated the need of a custom build step (as suggested in above in 1.a.B)
    3. As part of the Sp1 readme (http://go.microsoft.com/fwlink/?LinkId=210711 – section 2.4.1.2) we suggested refactoring of the project to make signing work. The suggestion was to redefine the "Key File" and "Delay Sign" property for the project using the IDE.
    4. However there were two issues with this solution:
      1. First, a typo in one our build files makes the above suggestion not work when you are targeting the Win32 configurations to build your projects.
      2. Second, we did not recognize that people using the old method and the VS2010 RTM workaround (mentioned above in 1.a.B) would be broken.

 

Workaround

The following workaround enables you to fix the two issues described above in 2.d.A and 2.d.B. You can work around this issue in two ways.

1. Change each project in your solution and redefine the "Key File" and "Delay Sign" properties on the linker. To do that follow these steps:

· Fix the typo in the build process (2.d.A):

  1. Open cmd prompt as administrator
  2. Go to %ProgramFiles(x86)%\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32
  3. Run "notepad Microsoft.Cpp.Win32.targets" (x64 targets are fine)
  4. Find the "LinkEmbedManifest" target (search for <Target Name="LinkEmbedManifest")
  5. Under the above target and in the task "<Link" perform the following steps.
  6. Change property  DelaySign
    1. From :       DelaySign                      ="%(Link.DelaySign)"
    2. To :            DelaySign                      ="$(LinkDelaySign)"
  7. Change property  KeyFile
    1. From :        KeyFile                        ="%(Link.KeyFile)"
    2. To:               KeyFile                        ="$(LinkKeyFile)"

· Redefine the "Key File" and "Delay Sign" properties used for signing your project (2.d.B):

  1. Right click on your project to bring up the properties page.
  2. Go to Configuration Properties->Linker->Advanced
  3. Overwrite the property "Key File" with your original key file. (for e.g. myfile.snk)
  4. This workaround eliminates the need of a custom build step (as described in section VS2010RTM-1.2)
  5. If you want to use the same project in VS2010 RTM and VS2010 SP1 make sure that when you redefine these properties they match their original value as set in VS2010 RTM.

2. Or, If you have a lot of projects and don't want do step 1 (above) , alternatively you could make the following changes to resurrect your VS2010 RTM behavior:

  1. Open cmd prompt as administrator
  2. Go to "%ProgramFiles(x86)%\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32"
  3. Run "notepad Microsoft.Cpp.Win32.targets"
  4. Move to "Link" target (search for <Target Name="Link")
  5. Add the following lines right after the first  "<PropertyGroup>" definition  and before the "<Link" task
    <PropertyGroup>
        <LinkDelaySign Condition="'$(LinkDelaySign)' == ''">%(Link.DelaySign)</LinkDelaySign>
        <LinkKeyFile Condition="'$(LinkKeyFile)' == ''">%(Link.KeyFile)</LinkKeyFile>
    </PropertyGroup>
  6. Find the "LinkEmbedManifest" target (search for <Target Name="LinkEmbedManifest")
  7. Under the above target and in the task "<Link" perform the following steps.
  8. Change property  DelaySign
    1. From :       DelaySign                      ="%(Link.DelaySign)"
    2. To :            DelaySign                      ="$(LinkDelaySign)"
  9. Change property  KeyFile
    1. From :        KeyFile                        ="%(Link.KeyFile)"
    2. To:               KeyFile                        ="$(LinkKeyFile)"
  10. Repeat the steps 1 to 5 for "%ProgramFiles(x86)%\MSBuild\Microsoft.Cpp\v4.0\Platforms\x64"
  11. Note that this solution will move you back to the VS2010 RTM behavior and you would still need to use the original workaround to sign your assemblies using sn.exe in the custom build step.

Thank you for helping us improve quality of the product. We understand that this change has caused much pain to you and for which we are sorry. Meanwhile we are also looking at other avenues to provide you with this fix.

 

Thanks,
Amit
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)