@Atlantisbase: NuGet will be available in all SKUs of Visual Studio 11. Unfortunately I don't think there is a way to get NuGet to install in Visual C# Express 2010 or Visual Basic Express 2010, but here is a workaround:
@Edson_Ferreira: I have seen this error come up when your login credentials actually lack the necessary permissions in SQL Server.
This is often the consequence of installing SQL Express using a different user account from the one you are trying to use it. It has happened to me when I take a virtual machine image prepared by another person.
One way to confirm this is your case would be to open SQL Server Management Studio logging in with your regular use account and attempt to create a database manually, e.g.:
USE master; CREATE DATABASE delete_me_next;
If you get the same error message you are getting is code first, there is your problem.
You should be able to work around this by running Visual Studio and your Code First app as an administrator every time, but this is not very safe so I would recommend that you rather grant the required permissions to your login use in SQL Server permanently.
There might be an easier way but you should be able to do the later this way:
Starting SQL Server Management Studio as an administrator (you should now be able to create and drop databases)
Expand the Root/Security/Logins node on the Object Explorer
If there is an entry for your Windows account right click and open properties, otherwise create a new login for your Windows user account.
Under Server Roles make sure there is a checkmark on a server role that has permissions to create databases, e.g. dbcreator or sysadmin.
If this is not the reason CREATE DATABASE is failing, another possibility is that the local account under which the SQL Server service is running doesn't have the necessary file system permissions to create files in the default location for new databases (i.e. under the ...\MSSQL\DATA directory).
@Lee Colins: Tugberk is right. DbContext and MVC both work with the "buddy class" pattern explained here: http://msdn.microsoft.com/en-us/library/ee256141.aspx (look for the MetadataType attribute in the article). This is your best option to specify data annotations for validtion if you are using code generation to get your entities. I would also add that DbContext validation checks string lenght and nullability constrainst specified in your EDM model without the need to have data annotations in your C# or VB classes.
I have just finished downloading and watching the video. Jasper is very cool!
I hope you will find a way to make the generated object model available in design-time on Visual Studio.
On the more conventional aspects, this looks similar to something ASP.NET already solves: How to get access to the page's object model while editing the code-behind file. Of course, what ASP.NET currently does is rather a smart hack and not really dynamic.
However, as one of you said, providing Intellisense on the names of new controls, classes or methods is uncharted territory. I don't know if/how other convention over configuration framework do this.
@Carl Perry: It is nice to have a face to go with your voice!
The recovery mechanism is part of a public Windows API that apps can hook into. I don't think Windows will automatically save data for any application that crashes unless it knows what to save and how (which is programmed by the app developer).
Sounds completely reasonable, but the fact is Internet Explorer needs to add such capability soon.
Sorry if this is a little off topic, but by comparison Firefox crashes less often and it is usually able to recover from a crash very gracefully by recovering all open tabs and sessions from disk.
Sorry I missed you in Sao Paulo. I really enjoyed Brazil and Sao Paulo in particular.
You asked some really good questions. Let me try to address them:
Hi again Surendra,
I did not see your answer until Saturday. Thanks for being so kind to give me your address. Unfortunatelly, I am not sure if you are receiving my messages because I am not getting any delivery confirmation. I just hope you are busy celebrating Vista shippment
Well, my email was actually a follow up to this thread, so here it is:
Sorry for trying to understand TxF and TxR from a database/managed developer point of view, but this is where I am coming from after all
Regarding the isolation level you describe, I guess if I had to explain TxF/TxR isolation level to a database geek, I would just tell him: “it’s just like REPEATABLE READS”.
Regarding the change in the APIs, I understand why you had to switch to an explicit model; however I grieve over what you had to give up.
While the problem with the implicit model is that you cannot opt-out of the ambient transaction, with the explicit model you cannot easily get transactional behavior through the “upper” programming stack without rewriting a good share of it.
I am sure that alternatives were carefully considered. However, if it is not abusing your tme, may I ask you about the merits and flaws of an alternate approach that I am thinking of? For sure I am not the only one that thought about this:
1. The original version of the API supports an ambient transaction and you mentioned that you could still expose that transaction handle at the thread level. I am not sure where things landed in the final Vista build.
2. Apparently, to work with any of the managed or unmanaged APIs that could take advantage of transactional semantics, you have to call a function with a file name (or key name for TxR) as a parameter at some point, and in case you are talking to one
of the higher level layers, those will ultimately invoke one of a small set of Win32 name-based APIs.
So, what if you could define a “transactional” moniker that you would need to preppend to the file name or registry key parameter in order to get “implicit” transactional semantics? I can imagine something like “txfile:”, but it could be something else.
I think this would have a few significant effects:
1. The non-transactional semantics of existing code would be preserved even in the presence of an ambient transaction, because hardcoded and existing strings would be lacking the moniker.
2. You would get back the possibility of using transactions with any existing API that takes a file name (or a key name) from Win32 through the .NET Framework, requiring minimal changes.
3. If you included something like this in a future version of Windows, you could still mix explicit, Vista-like calls, with implicit, moniker based calls enlisted in the same transaction.
I understand that this is not completely a clean approach and maybe it there is even something naïve about it. But in any case, it would be nice to learn what you think the tradeoffs are.
Thank you for listening! And congratulations for shipping this cool technology in Vista! It is really something I wish I have had a lot of times.
When I try to install the Visual Studio Template from the SDK, it says that it depends of the Web Application Projects add ins. I have Visual Studio 2005 SP1 beta, which contains a new version of Web Application Projects. But it does not work.
Sadly I cannot setup a separate computer for this.