Fix to blank LightSwitch app bug with Visual Studio 2012


I needed to populate a database I’m designing with some test data and thought to myself “LightSwitch will be ideal to knock out some screens”.

One hour later I got a LightSwitch screen to actually display! Until then all I got when running it in Desktop mode (the default) was a blank window hosting Silverlight (right click to verify)

After lots of searching and playing around I found the answer near the end of this very long thread

  1. Navigate to the Client.Properties folder inside your project
  2. Open OutofBrowserSettings.xml
  3. Change <SecuritySettings ElevatedPermissions=”Required” /> to <SecuritySettings ElevatedPermissions=”NotRequired” />
  4. And you may also want to then make the file readonly

 Now, when this happens again I will be able to find my own post to resolve it! Enjoy!

P.S. This isn’t specific to Visual Studio 2012 … but the post title corresponds to how I was searching :-)

Great FREE SQL Server 2012 webinars for UK partners in Nov to March


Microsoft UK has pulled together a great set of on-demand and live webinars to help you get to grips with SQL Server 2012. Enjoy!

NB: You will need to be a registered partner on the Microsoft Partner Network to take advantage of these.

Upcoming Live Technical Webinars:

Monthly Webinar series on SQL Server 2012 delivered by the UK team    Register

  • 10/11/2011  SQL Server 2012 Overview & Licensing (sorry – we all missed that one!)
  • 24/11/2011 SQL Server 2012 AlwaysOn
  • 08/12/2011 SQL Server 2012 Power View & PowerPivot v2
  • 22/12/2011 SQL Server 2012 Column Store Index and Database Replay
  • 05/01/2011 SQL Server 2012 Business Intelligence Semantic Model (BISM)
  • 19/01/2012 SQL Server 2012 on Windows Server Core Edition
  • 02/02/2012 SQL Server 2012 Security enhancements
  • 16/02/2012 SQL Server 2012 Data Quality Services & Master Data Services enhancements
  • 01/03/2012 SQL Server 2012 SSRS SharePoint integration & Alerting – Plus a series wrap up

On-Demand Technical:

For BI Consultants:

Technical Overview of New Features: SQL Server Code Name Denali

SQL Server: Data Discovery and Managed Self-Service BI

SQL Server Code Name Denali: Credible, Consistent Data

SQL Server Code Name Denali: Complete Data Warehousing Solution

For Database Administrators & Developers:

Technical Overview of New Features: SQL Server Code Name Denali

SQL Server Code Name Denali: Required 9s and Data Protection

SQL Server Code Name Denali: Blazing Fast Performance

SQL Server Code Name Denali: Organizational Compliance

SQL Server Code Name Denali: Scale on Demand

For Application Developers:

Technical Overview of New Features: SQL Server Code Name Denali

SQL Server Code Name Denali: Optimized Developer Productivity

SQL Server Code Name Denali: Extend Data Virtually Anywhere

On-Demand Licensing:

Workshops on Licensing:

  • What’s new in SQL Server 2012 and how does it affect you    Dec 13th Register

Universal ASP.NET Providers??? Getting SQL Azure to handle your Session State


While pulling together this post on the August release of the Windows Azure Tools I noted that the ASP.NET MVC 3 template included “the new universal ASP.Net providers that support SQL Azure”. Which made me pause and think … “What universal ASP.NET Providers?”

Looks like their existence completely passed me by :-)

Scott Hanselman summarised the purpose of the Universal Providers back in June. Simply put they extend Session, Membership, Roles and Profile support to include SQL Compact Edition and SQL Azure. In all other ways they work like the existing SQL-based providers. They are released via a NuGet Package (something else I need to dig into more).

What this means is we now have a supported way of doing session state with SQL Azure, rather than via workarounds (e.g. this one from Wayne)

By default, the NuGet package sets the connection string to use a SQL Server Express database:

"Source=.\SQLEXPRESS;

AttachDbFilename=|DataDirectory|\aspnetdb.mdf;

Initial Catalog=aspnet;

Integrated Security=True;

User Instance=True;

MultipleActiveResultSets=True" 

providerName="System.Data.SqlClient" 

For SQL Azure you simply change to:

“data source=myDNSName;

Initial Catalog=myDatabase;

User ID=myUserName;

Password=myPassword;

Encrypt=true;

Trusted_Connection=false;

MultipleActiveResultSets=True" 

providerName="System.Data.SqlClient”

Related Links

No OLEDB support in SQL Server post Denali


The next release of Microsoft SQL Server, codename “Denali”, will be the last release to support OLE DB. OLE DB will be supported for 7 years from launch, the life of Denali support, to allow you a large window of opportunity for changing your applications before the deprecation. This deprecation applies to the Microsoft SQL Server OLE DB provider only. Other OLE DB providers as well as the OLE DB standard will continue to be supported until explicitly announced. Read more over on the sqlnativeclient blog.

A little history:

Today there are many different ways to connect to SQL Server. What you normally require is a consumer (e.g. the ADO.NET Entity Framework) and a provider (e.g. an ADO.NET Data Provider). ADO.NET Data Providers are the most recent manifestation of providers and are the preferred way to connect to SQL Server today if your consumer is running on the Windows platform. The ADO.NET Data Provider model allows “older” providers to be consumed via modern ADO.NET clients – specifically that means ODBC and OLE DB drivers. This feature is very cool although there are now many great native ADO.NET Data Providers.

Now lets briefly recap on ODBC and OLEDB:

  • ODBC emerged around 1992. It replaced the world of DB Library, ESQL for C et al and soon became a “standard”
  • OLEDB appeared 4 years later in 1996 (which happens to be when I joined Microsoft)

OLE DB was created to be the successor to ODBC – expanding the supported data sources/models to include things other than relational databases. Notably OLEDB was tightly tied to a Windows only technology (COM) whilst ODBC was not (Although we did try and take COM cross platform via partners)

ODBC never did get replaced. What actually happened is that ODBC remained the dominant of the two technologies for many scenarios – and became increasingly used on none Windows platforms and has become the de-facto industry standard for native relational data access.

Therefore we find ourselves in a world where:

  • A new Windows client to SQL Server/SQL Azure will most likely use the ADO.NET Data Provider for SQL Server
  • A new none Windows client to SQL Server/SQL Azure will most likely use the ODBC driver for SQL Server

Notice no mention of … OLEDB.

I know many UK ISVs with older applications that do use OLEDB. Please do check out the related links below and remember this is just about the SQL Server OLEDB Provider.

Related Links

Annual SQL Server Connectivity Survey – live until 9th September 2011


The Microsoft SQL Server team has been interacting on a regular basis with developers and users in the form of surveys. If you have 15mins spare and would like to do your bit to help shape the roadmap for SQL Server then please pop over to http://www.zoomerang.com/Survey/WEB22CS45XT9FE/

And…

My own simple one question version if you only have one minute to spare. Apologies in advance for stuff I left out!

http://zohopolls.com/external/ericnel/how-much-development-focus-will-you-have-on-each-of-these-database-technologies

Related Links:

Giving feedback on SQL Server “Denali” CTP3 and SQL Azure


SQL Server “Denali” is at CTP3 – and would therefore very much welcome feedback.

SQL Azure continues an aggressive cycle of release -  and would therefore very much welcome feedback.

Which is why we have https://connect.microsoft.com/SQLServer/Feedback. A great place to give feedback and to to see what others care about.

For SQL Azure (and the Windows Azure Platform in general) we also have http://www.mygreatwindowsazureidea.com

Thanks in advance…

Q&A: Will my favourite ORM Foo work with SQL Azure?


Note: Cross posted from IUpdateable from Eric Nelson.

Permalink

short answer: Quite probably, as SQL Azure is very similar to SQL Server

longer answer: Object Relational Mappers (ORMs) that work with SQL Server are likely but not guaranteed to work with SQL Azure. The differences between the RDBMS versions are small – but may cause problems, for example in tools used to create the mapping between objects and tables or in generated SQL from the ORM which expects “certain things” :-)

More specifically:

  • ADO.NET Entity Framework / LINQ to Entities can be used with SQL Azure, but the Visual Studio designer does not currently work. You will need to point the designer at a version of your database running of SQL Server to create the mapping, then change the connection details to run against SQL Azure.
  • LINQ to SQL has similar issues to ADO.NET Entity Framework above
  • NHibernate can be used against SQL Azure
  • DevExpress XPO supports SQL Azure from version 9.3
  • DataObjects.Net supports SQL Azure
  • Open Access from Telerik works “seamlessly”  – their words not mine :-)

The list above is by no means comprehensive – please leave a comment with details of other ORMs that work (or do not work) with SQL Azure.

Related Links: