void GetTempFolderPathHighLevel(std::wstring& path)
{
  path = Windows::Storage::ApplicationData::Current->TemporaryFolder->Path->Data();
}

Short, simple, and to the point. The equivalent low level code to get this is heinous:

#include <windows.storage.h>
#include <wrl/client.h>
#include <wrl/wrappers/corewrappers.h>

HRESULT GetTempFolderPath(std::wstring& path)
{
  HRESULT hr;
  Microsoft::WRL::ComPtr<ABI::Windows::Storage::IApplicationDataStatics> applicationDataStatics;

  hr = Windows::Foundation::GetActivationFactory(Microsoft::WRL::Wrappers::HStringReference(RuntimeClass_Windows_Storage_ApplicationData).Get(), &applicationDataStatics);
  if (FAILED(hr))
  {
    return hr;
  }

  Microsoft::WRL::ComPtr<ABI::Windows::Storage::IApplicationData> applicationData;
  hr = applicationDataStatics->get_Current(&applicationData);
  if (FAILED(hr))
  {
    return hr;
  }

  Microsoft::WRL::ComPtr<ABI::Windows::Storage::IStorageFolder> storageFolder;
  hr = applicationData->get_TemporaryFolder(&storageFolder);
  if (FAILED(hr))
  {
    return hr;
  }

  Microsoft::WRL::ComPtr<ABI::Windows::Storage::IStorageItem> storageItem;
  hr = storageFolder.As(&storageItem);
  if (FAILED(hr))
  {
    return hr;
  }

  HSTRING folderName;
  hr = storageItem->get_Path(&folderName);
  if (FAILED(hr))
  {
    return hr;
  }

  UINT32 length;
  PCWSTR value = WindowsGetStringRawBuffer(folderName, &length);
  path = value;
  WindowsDeleteString(folderName);
  return S_OK;
}

Since we do our own Direct3D rendering we can get better performance with polygons and polylines on our map by managing the vertices ourselves and just adjusting the camera per frame instead of pushing across new vertices. As a side effect of this MapPolygon and MapPolyline do not descend from UIElement and can't be placed just anywhere in the UI tree but instead need to be children of the separate Map.ShapeLayers property to differentiate them from XAML overlay controls. XAML children still go on the Children property like you would expect.

<bm:Map x:Name="map" Width="800" Height="600" Credentials="INSERT_YOUR_BING_MAPS_KEY">
  <!-- UIElements go under Map.Children -->
  <bm:Map.Children>
    <bm:Pushpin bm:MapLayer.PositionAnchor="11,11">
      <bm:MapLayer.Position>
        <bm:Location Latitude="0" Longitude="0" />
      </bm:MapLayer.Position>
    </bm:Pushpin>
  </bm:Map.Children>
  <!-- MapPolygon and MapPolyline go under Map.ShapeLayers -->
  <bm:Map.ShapeLayers>
    <bm:MapShapeLayer>
      <bm:MapShapeLayer.Shapes>
        <bm:MapPolygon>
          <bm:MapPolygon.Locations>
            <bm:Location Latitude="-10" Longitude="-10" />
            <bm:Location Latitude="-10" Longitude="10" />
            <bm:Location Latitude="10" Longitude="10" />
            <bm:Location Latitude="10" Longitude="-10" />
          </bm:MapPolygon.Locations>
        </bm:MapPolygon>
      </bm:MapShapeLayer.Shapes>
    </bm:MapShapeLayer>
  </bm:Map.ShapeLayers>
</bm:Map>

Side note: there's a XAML compiler bug in the consumer preview that prevents setting FillColor on MapPolygon but you can set it via code fine or wait until the final release where it can be set from XAML as well.

Side note 2: We're already hard at work creating the final version of the Map control with tons of tweaks and fixes. As an example Pushpin no longer requires setting PositionAnchor on it as it will default to the center of the pushpin.

<bm:Map Center="0,0" />

On the Win8 metro version of the map this looks a bit different:

<bm:Map>
  <bm:Map.Center>
    <bm:Location Latitude="0" Longitude="0" />
  </bm:Map.Center>
</bm:Map>

Other properties are similarly affected. The attached property MapLayer.Position for example:

<bm:Map>
  <bm:Map.Children>
    <Button Width="100" Height="40" Content="Button" bm:MapLayer.PositionAnchor="50,40" Background="Black">
      <bm:MapLayer.Position>
        <bm:Location Latitude="0" Longitude="0" />
      </bm:MapLayer.Position>
    </Button>
  </bm:Map.Children>
</bm:Map>

Note that MapLayer.PositionAnchor can be set inline since it is of type Point which is natively supported by the Xaml parser whereas it does not know how to convert from a string to a Location object so it needs a little help there.

It's also easy enough to use Bing Maps in an application from scratch. First add a Reference to Bing Maps for C#, C++, or Visual Basic (Beta) and Microsoft Visual C++ Runtime Package (if you're writing a managed app, C++ only needs Bing Maps).

If you try to build at this point you'll be presented with a most confusing set of error messages:

• Could not find SDK "Microsoft.VCLibs, Version=11.0".
• "APPX" attributes were found in the SDK manifest file however none of the attributes matched the targeted configuration and architecture and no "APPX" attribute without configuration and architecture could be found. If an appx is required then the project will fail at runtime.
• The referenced component 'Microsoft Visual C++ Runtime Package' could not be found.

Don't be alarmed. This just means you're writing a managed application and have left the platform target at the default Any CPU and both Bing Maps and Visual C++ Runtime require a specific architecture to be set. Change the Active solution platform to x64 or x86 and then it will build properly. The Visual C++ Runtime package is required to deploy on computers that do not have Visual Studio installed. To use the Map control you can drag it from the Toolbox and drop it on your page or declare it yourself with the following two snippets:

xmlns:bm="using:Bing.Maps"

<bm:Map Width="800" Height="600" Credentials="INSERT_YOUR_BING_MAPS_KEY" />

You will need a Bing Maps Key to use the map but fortunately we have generous pre-release licensing terms that permit you to use it for free during the beta period. You can read more the licensing terms on the Bing Maps blog. For digging deeper we have also worked hard to make sure the documentation is helpful and up to date.

.NET assemblies contain a rich set of metadata for use by the run time, debugger, and compiler. This information is stored in the assembly whether it will be used or not which for certain types of shipping assemblies is unnecessary. For example when you create a new automatic property:

public int MyProperty { get; set; }

The compiler generates the following disassembled code:

.field private int32 '<MyProperty>k__BackingField'

.method public hidebysig specialname instance int32

          get_MyProperty() cil managed

  {

    .custom instance void [mscorlib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor() = ( 01 00 00 00 )

    // Code size       11 (0xb)

    .maxstack  1

    .locals init (int32 V_0)

    IL_0000:  ldarg.0

    IL_0001:  ldfld      int32 ConsoleApplication1.Test::'<MyProperty>k__BackingField'

    IL_0006:  stloc.0

    IL_0007:  br.s       IL_0009

    IL_0009:  ldloc.0

    IL_000a:  ret

  } // end of method Program::get_MyProperty

  .method private hidebysig specialname instance void

          set_MyProperty(int32 'value') cil managed

  {

    .custom instance void [mscorlib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor() = ( 01 00 00 00 )

    // Code size       8 (0x8)

    .maxstack  8

    IL_0000:  ldarg.0

    IL_0001:  ldarg.1

    IL_0002:  stfld      int32 ConsoleApplication1.Test'<MyProperty>k__BackingField'

    IL_0007:  ret

  } // end of method Program::set_MyProperty

Note the extra CompilerGeneratedAttribute that the compiler inserts to note that this code was generated by the compiler. This attribute is used by the debugger to step over code but when you’re done debugging and ready to ship it adds little value.

Thanks to the Common Compiler Infrastructure Metadata Components we can easily create a tool to remove attributes from an assembly. Using MetadataMutor we override Visit(List<ICustomAttribute>) and return a modified list of attributes by removing all attributes of a certain type:

public class AttributeMutator : MetadataMutator

{

    private Dictionary<string, string> attributesToRemove;

    public AttributeMutator(IMetadataHost host, IEnumerable<string> attributesToRemove)

        : base(host)

    {

        this.attributesToRemove = new Dictionary<string, string>();

        foreach (string attribute in attributesToRemove)

        {

            this.attributesToRemove.Add(attribute.ToUpperInvariant(), attribute);

        }

    }

    public override List<ICustomAttribute> Visit(List<ICustomAttribute> customAttributes)

    {

        List<ICustomAttribute> result = new List<ICustomAttribute>(customAttributes);

        for (int i = result.Count - 1; i >= 0; i--)

        {

            if (this.attributesToRemove.ContainsKey(result[i].Type.ToString().ToUpperInvariant()))

            {

                result.RemoveAt(i);

            }

        }

        return base.Visit(result);

    }

}

The rest of the code to read and write assemblies can be copied from the CCI samples.

Download the Visual Studio 2010 project

To use this program run:

               StripAttributes.exe C:\Input\MyAssembly.dll C:\Output @attributes.txt

where attributes.txt is a list of attributes, one per line, to be removed from the assembly. The resulting file is written to C:\Output. Since the assembly is rewritten it will need to be resigned with sn.exe before shipping.

The cost savings per assembly will vary depending on your attribute usage and how the PE pages line up. Sometimes no savings can be achieved even if attributes are removed because the assembly is written in 512 byte chunks.

For desktop CLR assemblies disk size is relatively unimportant but when the end user has to download your code (Silverlight for example) every byte matters.

1. First set your project to build in Release mode.
2. Next go to Tools|Options|Debugging and uncheck both Suppress JIT optimization on module load (Managed only) and Enable Just My Code (Managed only)

Now you can run your project and set a breakpoint where you want to look at code and go to Debug | Windows | Disassembly to get an annotated disassembly like the following: 

The .NET runtime does first try to create a new OutOfMemoryException instance but if it fails it will fall back to the preallocated instance so there is always an exception available to be thrown.

Some other exceptions are preallocated: StackOverflowException, ExecutionEngineException, and ThreadAbortException.

After the pre-requisites have been validated VirtualEarth3D.msi or VirtualEarth3D64.msi are downloaded and installed.  The 64 bit MSI contains both 32 and 64 bit modules so you can run internet explorer in 32 or 64 bit mode. The MSI log is stored in MsiInstall.log, also in the Temp folder.

So what errors go to what log?

• If the error happens in the Setup program, for example a failure to download a prerequisite or the MSI, VirtualEarth3DInstallLog.txt will have an error message with the details.
• If the error happens once Setup starts running the Virtual Earth 3D MSI MsiInstall.log will contain the details.