VB and C# enhancements in VS 2010
Choosing a programming language is a personal choice that each programmer gets to make. It is akin to choosing a flavor of ice cream - there are many great options out there, but your favorite flavor is a matter of personal preference.
In Visual Studio 2010, we’ve made several enhancements to our two most popular languages, Visual Basic and C#, to give programmers all the tools they need to build great software no matter which language they prefer.
Visual Basic
The Visual Basic team focused on adding productivity features to the language so developers can get more done in fewer lines of code. The most common customer request for Visual Basic is to remove the underscore (“_”) character when breaking a code statement across multiple lines in most cases. Visual Basic 10 introduces implicit line continuation, which removes the need for the underscore character in most cases.
Function Filter(
ByVal customers As List(Of Customer),
ByVal orderCount As Integer
)
Dimquery =
FromcIncustomers
Where c.Orders.Count >
orderCount
Selectc
Another new productivity feature is auto-implemented properties. With auto-implemented properties, lines of boiler-plate property implementation code can be replaced with simple one-line declarations. Previously, property declarations often looked like this:
Private _FavoriteFlavor As String = "Butter Pecan"
Property FavoriteFlavor() As String
Get
Return _FavoriteFlavor
End Get
Set(ByVal value As String)
_FavoriteFlavor = value
End Set
End Property
Private _FlavorList As New List(Of Flavor)
Property FlavorList() As List(Of Flavor)
Get
Return _FlavorList
End Get
Set(ByVal value As String)
_FlavorList = value
End Set
End Property
Now property declarations can be declared much more simply:
Property FavoriteFlavor As String = "Butter Pecan"
Property FlavorList As New List(Of Flavor)
Collection initializers and array literals are simpler as well. Collections can now be initialized when they’re declared, and the type of array literals is inferred by the compiler.
Dim toppings = New List(Of String) From
{
"sprinkles",
"chocolate chips",
"strawberries"
}
Dim cones = {"sugar cone", "waffle cone"} 'the type String() is inferred
Visual Basic 10.0 now has better support for lambdas. Lambdas can now contain expressions that don’t return a value, as the Sub keyword indicates below:
Array.ForEach(toppings, Sub(n) Console.WriteLine(n))
Sometimes you’d like to do more complex work inside a lambda declaration. Visual Basic 10.0 supports multiline lambdas. The compiler will infer parameter and return types where possible just like in regular lambdas.
Dim doubleDown = Function(n As String)
If n.StartsWith("s") Then
Return "extra " & n
Else
Return n
End If
End Function
Interoperating with dynamic language code such as Python and Ruby has become simpler in Visual Basic 10.0. For example, the following code snippet calls a method defined in a Python library “math.py”:
Dim mathLib As Object = python.UseFile("math.py")
Dim firstNumber = 44.2
Dim secondNumber = 9.5
mathLib.PowerOf(firstNumber, secondNumber)
C#
C# 4.0’s major themes are interoperability with dynamic programming paradigms and improved Office programmability. Dynamic lookup, a new feature in C# 4.0, allows you to use and manipulate an object from IronPython, IronRuby, JScript, the HTML DOM, or a standard .NET library in the same way, no matter where it came from. Language enhancements such as named and optional parameters and improved support for COM clients give C# developers who are working with Office APIs the same great experience that Visual Basic developers have enjoyed.
Adding the new dynamic keyword to your code allows its type to be resolved dynamically at runtime rather than statically at compile-time. This allows dynamic languages to expose their objects to C# in a way that feels natural to a C# programmer:
dynamic dynamicObject = GetDynamicObjectFromRuby();
dynamicObject.Foo(7);
dynamicObject.Property = "Property value";
dynamicObject[0] = "Indexed value";
Optional method parameters are familiar to Visual Basic and C++ programmers and are now available for C# programmers. Optional parameters are declared with a default value in the method signature, as follows:
private void CreateNewStudent(string name, int currentCredits = 0, int year = 1)
The method above can be called in any of the following ways:
CreateNewStudent("Chloe");
CreateNewStudent("Zoe", 16);
CreateNewStudent("Joey", 40, 2);
To omit the currentCredits parameter value but specify the year parameter, the new named arguments feature (highlighted) can be used. All of the following are also valid calls:
CreateNewStudent("Jill", year: 2);
CreateNewStudent(name: "Bill", currentCredits: 30, year: 2);
CreateNewStudent("Will", currentCredits: 4);
Named arguments are also a great way to write self-documenting calls to your existing methods, even if they don’t use optional parameters.
Learn More
Find out more about Visual Studio 2010’s language enhancements and download samples on the VB Futures site and the C# Futures site. To play with the new features, download and install Visual Studio Beta 1, then join the conversation.
Namaste!
Comments
Anonymous
August 19, 2009
The interesting thing re. C# dynamic is: what's the signature of 'GetDynamicObjectFromRuby' ? E.g. does it return System.Object?Anonymous
August 19, 2009
Or is the return type of GetDynamicObjectFromRuby() marked as being 'dynamic' ?Anonymous
August 19, 2009
I see VB is getting auto-implemented properties. It looks like you can actually initialise them as well, which you can't currently do in C#, which makes auto properties in C# practically useless. Why isn't this deficiency being addressed in C#? See the following request on Connect from over a year ago: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=361647Anonymous
August 19, 2009
The comment has been removedAnonymous
August 20, 2009
The big missing LINQ is the ability to do easy left/right outer joins. Please provide a leftjoin and rightjoin command to linq so that we don't have to create the ugliest queries on earth to do this basic requirement! Pretty please!Anonymous
August 20, 2009
Soma, Why have a new way of assigning values using colon? CreateNewStudent(name: "Bill", currentCredits: 30, year: 2); Why can't we stick with equal operator? CreateNewStudent(name = "Bill", currentCredits = 30, year = 2);Anonymous
August 20, 2009
Is there any reason to VB.NET developer to use underscore?Anonymous
August 20, 2009
Fully agree with danieldsmith and James Hancock. Why isn't C# getting those advantages and why is LINQ missing left/right joins? Moreover, why isn't there a INSERT, DELETE and UPDATE statements with LINQ? For example: from s in MyCollection where s.City == "Test City" update s.City = "My City"Anonymous
August 20, 2009
The comment has been removedAnonymous
August 20, 2009
The comment has been removedAnonymous
August 20, 2009
The comment has been removedAnonymous
August 20, 2009
I rest my case about truely ugly syntax that is almost impossible to memorize so I have ot look it up every single time :) The concept of left and right joins are simple and required and obvious and supported by all databases. Return value, but if null, return null for values. Lots of sense and should be simple with leftjoin, rightjoin. Syntaxically you could just have optionaljoin and make sure that it's left to right, but I don't think it would be as obvious. My point is that the syntax is ulgy and difficult and that is part of what makes linq nice, obvious and simple queries. Try debugging that mess above when there are 15 of them in one query and you'll understand the problem.Anonymous
August 20, 2009
@Mads Torgersen: So, if its hard, you won't do it? :-) I think the "Update" and "Delete" feature needs to be tied closely to the regualr programmer's view of the world too! It is a very useful feature. Look at this simple problem for example: Imagine that we have to update a property for some employees in a collection that meets some condition. This is one way how we do it today: var emp = from e in EmployeeCollection where e.Salary > 100000 select e; foreach(Employee ee in emp) // or emp.ToList() { ee.Bonus = 100; } With the easy "Update" feature that I requested before this would be reduced to: var emp = from e in EmployeeCollection where e.Salary > 100000 update e.Bonus = 100; More efficient, elegant and easy to read. Aren't those 3 big enough reasons to try and get that to .NET developers? My example is really simple, imagine the more interesting cases that can be simplified! This also helps presentation technologies like Silverlight and WPF as well in data-binding scenarios.Anonymous
August 20, 2009
@James: In our view, left joins exist because of the limitations of a flat table based model like SQL's. You want each of the left elements paired with a list of the right elements that they join with. This is hierarchical; list within lists (or sets within sets) and tables can't express that, so left outer joins are the best approximation. In an object-oriented programming language we don't have the same restriction on the shape of the result. Group join gives you the structure you really want. The "ugly" (is it that ugly?) example I wrote was to illustrate that you can get left join semantics if you really want to (for instance if you need to subsequently pour it into a flat table), but the overall point is you don't often want to. Yes it is a different perspective, yes it takes a bit of getting used to. But once you get there, you will never miss your left joins again.Anonymous
August 20, 2009
@Sam: No as a matter of principle we don't do difficult stuff :-). Seriously, once the examples you want to improve get more complicated, so does the solution. I won't go into details here, just mention one of many complicating factors: transactions. No-one has succeeded in coming up with an abstraction of the update features that is a general as LINQ, and it is not for lack of trying. We may get there.Anonymous
August 20, 2009
@Daniel: You bring up the subject of how we decide what to put in the languages, so let me say a little bit about how we approach programming language design. Our goal is to have programming languages that are good to use, remain relevant in the face of emerging needs in the developer community, and live for a long time. We can only evolve the languages at a certain pace before a) learning the next version becomes too much of a jump, and b) the language “fills up” to quickly and becomes unwieldy as a whole. As a consequence we have a very tight “budget” at every release – and over the whole lifetime of the language – for how much we can add. Anders Hejlsberg usually says that “every feature starts with minus a thousand points.” In other words, it is not enough for a feature to be good and useful to get into VB and C#; there are easily enough good and useful features in the world to fill up a hundred programming languages to the brim. So we need a very judicious approach to choosing. We strive to maximize both the tactic and strategic value, so that what we add will have a huge positive impact on current scenarios, as well as being a great and durable addition for the long term. We have to make sure that a feature – or set of features – is principled and general, and meshes well with the existing language, as well as with other developments on the platform. We also need to exercise a careful balance between being reactive (responding to existing customer needs) and proactive (providing new opportunities to customers). All of this is far from an exact science. We inform these decisions through massive and multi-faceted interactions with customers, through Connect (yes we do read and evaluate every single suggestion), blogs, conferences, online forums, MVP programs, etc. And once we understand the problems that we want to try to solve, we expend enormous effort on the team and across the company on innovation to find the most effective, simple, general, efficient and elegant solutions. Now let’s look at C# 4.0. Two of the most frequently and urgently expressed customer pain points are: a) Office programming (and other COM interop) is extremely ungratifying in C#, and b) VB and C# differ in arbitrary, important and frustrating ways. On top of this, a huge new opportunity is opening up: c) The addition of dynamic programming languages on .NET, and in particular a wonderful implementation platform, the DLR (Dynamic Language Runtime), which provides for efficient cross-language dynamic dispatch of operations with a generality and usability that we believe is truly game changing. From this situation come our top priorities: Fix parity with VB, fix Office programming, and facilitate smooth dynamic interop. The two former points are more backward looking – fix existing problems. The third is forward-looking, and will have to prove its worth in the years to come. No platform has ever offered this degree of tight, safe and efficient integration between static and dynamic worlds – we are breaking new ground here. We think and hope that this will have a huge impact in the future, will eventually be imitated by competitors and will in the long run come to be seen as the first and defining strong bridge across that decades-old and utterly confounding gulf between the separate worlds of static and dynamic systems. The dynamic feature has been reviewed extensively by customers, and has in fact changed dramatically over the time of its design as a direct result of customer feedback on the very early ideas we shared. We have strong evidence from customers already that we are right to do dynamic and we are doing dynamic right. So much for how we set the course for C# 4.0. What does the future hold? We will continue to look at what customers are struggling with. We will continue to evaluate and be inspired by the hundreds of suggestions on connect, most of which, by simple but heart-wrenching arithmetic, will never get into the language. We will try to remove the biggest stones in the road already travelled, while also building great bridges to new lands. Now keep that feedback coming! MadsAnonymous
August 20, 2009
The comment has been removedAnonymous
August 20, 2009
@Mads Torgersen: If the C#/.NET teams at Microsoft can achieve this, I want to present them the Turing award! :-) Keep up the good work, although I think .NET 5 will be much more interesting thanks to Anders Hejlsberg's video on future of languages.Anonymous
August 21, 2009
Your arguments about left/right join don't make sense. If I'm using EF and I choose not to create a direct object and instead just leave the reference, or you have a reference that applies to multiple tables and EF can't handle it because they left out that functionality, you will definately need left/right outerjoin support because our way is messy and impossible to try and maintain when you're talking about dozens of tabes that may be left joined. The same is true of objects. If I have two objects that referenc eachother based on a key, but I want to return all of the items in the first, and the second if there is a match, but give me the first even if there isn't a second that matches, you could either do it your way, which works,but is a mess, or you could do my way: from o in object1 leftjoin c in object2 on o.ID = c.ID where blahblah blah. My way is incremental, and clear what's related to what, and obvious what it's doing. Yor way creates new fake objects/tables and then handles it with the unrelated reference that is impossile to figure out which is which without having to carefully read every part of the query over an over again. Sorry, but your argument doesn't hold water. This always happens, even in the object world and we don't need to make it more difficult, not less.Anonymous
August 21, 2009
The comment has been removedAnonymous
August 21, 2009
@Mads to Sam #2: [Coming up with a provider neutral abstraction over queries was hard enough! The insert/update/delete paradigm is strongly tied to a table-based view of the world and much less universally applicable than the set of query operators we have for LINQ.] Mads, can you please provide an example where UPDATE in LINQ does not make sense? Sure, there will be an issue with database query from multiple tables, but you can specify which table you would like to be updated. You can update XML, can you? Other LINQ targets should be less complicate, or I'm missing somthing? Please give me some examples where UPDATE in LINQ would not make sense even though object is updatable (not read only) I do not see why UPDATE is relational database-specific operation. Properies, as well as collection and array member values are get updated too. BTW, having DELETE in LINQ would be sweet too!Anonymous
August 21, 2009
@James Hancock In .NET 4.0, the Entity Framework recognizes various LINQ outer join patterns. As Mads suggests, you will need to use group joins and structured result types in 3.5 SP1 however.Anonymous
August 21, 2009
@James: I don’t know the Entity Framework well enough to be able to speak to what it supports or not, sorry. I think we are talking about slightly different kinds of examples, which may be why I don’t make sense to you . The difference, I think, is that I am talking about many-to-many relationships and you are talking about one-to-one. So let me address both kinds here. Many-to-many first: the question I want to answer in my example is this: “For each customer, which products are produced in their home city?” I can ask the question like this: from c in Customers join p in Products on c.City equals p.City into ps select new { Customer = c, Products = ps } What do you get back? the customers, paired with the list of products produced where they live. In other words: “For each customer the products that are produced in their home city.” Compare with the original question above! It doesn’t get more natural than that! Now, your scenario seems to involve a one-to-one relationship, where the second “one” is optional, i.e. zero/one. You want to pull these strongly coupled objects together based on a shared key. This doesn’t often happen in practice in an object-oriented model, or one that is modeled through an object-relational (O/R) framework (such as EF or LINQ to SQL), because the relationship would typically already be represented more directly by an object reference one or both ways, or even by an inheritance relationship. So having a primitive operator specifically for the purpose of this case doesn’t seem right. In general, the foremost task of an O/R framework is to hide key-based relationships behind more direct representations. But say that you don’t have that structure already; maybe you are in fact out to establish it with the query. Clearly the output of a left join would give you the right kind of result here (one row per left element, with a right element or nothing attached to it), but only because you happen to know that the relationship is one-to-one. How would you do it in LINQ? There are multiple options (e.g. using nested queries), but the one I like best still uses the group join. Here is an example to illustrate. Say that you are representing Employees. Some of these are Partners and have extra data associated with them. In an object-oriented modeling you would have Partner derive from Employee, or at least Employees would have a nullable PartnerInfo property on them, but say that we don’t have that luxury: The model we are presented with keeps them separate, correlating by an ID key. Now to get all the Employee/Partner relationships I can write: from e in Employees join p in Partners on e.ID equals p.ID into ps let p = ps.SingleOrDefault() // throw if there is more than one partner info for an employee select new { Employee = e, PartnerInfo = p } // or whatever projection you wish to make In words: “for each employee, give me the single associated partner info, if available.” Another approach would be to model the PartnerInfo reference yourself through an extension method: public static class EmployeeHelpers { public static Partner GetPartnerInfo(this Employee employee) { return Partners.Where(p => p.ID == employee.ID).SingleOrDefault(); } } Now you can walk up to an employee e and say var p = e.GetPartnerInfo(); Compare these two approaches: both get collections of partner infos for each employee, and call SingleOrDefault on them to get null in the absence of a partner info and an exception (a good thing) if there are too many. They get those collections in different ways; one by group joining and one with a “where” query, but the “SingleOrDefault” logic applies equally to both; it is not strongly tied to the joining as it would have been with a leftjoin operation. We compose primitive operations instead of hardcoding complex ones. Granted it makes things more different from SQL. But we’re in a full scale programming language here; we have the ability to compose primitives, to abstract over those compositions, and to represent data with deep structures. Shouldn’t we take advantage of that? MadsAnonymous
August 21, 2009
@tye: Naming the LINQ operators was a delicate balance: allude to the SQL keywords to keep the intuition, but still introduce a new, object-oriented mindset. I still don't know what is the lesser evil: risk confusion, or risk alienation :-) In practice I find that LINQ takes a bit of getting used to regardless of what camp you come from, but that the flexibility of the model really grows on you once you are beyond the learning curve. I can see how the similarity-yet-difference to SQL of some of the LINQ constructs can actively hinder mastery in some cases - that point is well taken. I recommend attacking LINQ with a good book and an open mind.Anonymous
August 21, 2009
The comment has been removedAnonymous
August 21, 2009
@Mads Torgersen: In the mean time, would it make sense to abstract out the "foreach" part that does the "Update" in my earlier example into LINQ? In other words, provide "Update" in LINQ - but in the background the runtime can do what the foreach does. At least make it available for updating simple properties of objects. I don't understand how/why this is not do-able today. Btw, your reply to Konsstantin is using way too much abstracted language - an unnecessary evil? ;-)Anonymous
August 21, 2009
@Sam: Sorry, occupational hazard :-). To summarize/clarify ... On update in LINQ queries: we could add that in a future release, as a syntactic convenience. I don't know if we will. On a general LINQ-like framework for modifying data: we don't have a good way of doing it or a strong customer ask for it, so that is not in the cards.Anonymous
August 24, 2009
And still no real support for pointers.I'm going to push this barrow as far as I can. MS staff keep telling me there is no demand!! Yet the web has plenty of moans and attempted workarounds using marshalling in C# Pointers - GetThem, SetThem, SecureThem This thread must almost be out of date. But presumably someone will still read a new posting. Also, since beta1 is already out you can only react now to bugs rather than bad design. Nevertheless I must express my extreme dismay at the abysmal treatment of VB pointers. They are the crux to any inventive programming. There are three needs for effective use of pointers: GetThem, somewhere to SetThem and somewhere to safely retain them. In VB5 I had all three for some needs (arrays, user types and some other structures) and used classes with static objects when needed. I bought VS2005 and threw it out!! I cannot for the life of me understand WHY MS should be so irresponsible. With the bragging of a CRL why the devil is it that C++, C#, J# and VB do not yet have a common access to the same language elements. As someone said "We should all be playing in the same sandpit." The trouble is that we all have too little power, and too little voice. Too few alternatives. I explored Delphi and C++ with CodeGear and found it wanting. As a consequence we ordinary folk spend our nights playing with ourselves instead of trying to change things. And that leaves you MS guys free to play with yourselves. Thats all well and good and private but wasteful. But when you in MS start playing with ME I get offended. For all our sakes, please give ALL OF US stable methods and common syntax to GetThem. You've got access to Them! For all our sakes, please give ALL OF US stable structures with common properties at which to SetThem. For all our sakes; please for ALL OF US, if you have to change a structure INCLUDE the old structure as a field within the new. NO - I WILL NOT BE BUYING VS2010 for the same reasons I did not buy VS2008 and THREW OUT VS2005. I'll get by with VB5 and ASM for the difficult bits (After all, thats where I (now 72) had to start). Why do I hang on to VB? Its the only worthwhile language that properly defines its code loops. IF..ELSE..ENDIF; Do..WHILE etc compared with a forest of {..} in C, C++, C# and j#. Only FORTRAN defines loops more definitively. DO 100.. ..100 CONTINUE. Even PASCAL (DELPHI) uses END; but only sometimes and too often. Why is that important? It leads to easy, faster and accurate reading and so less confusion in 'over the page(s)' code 'blocks', fewer coding errors and faster coding. It has been worth the price in the past, but with poor backward compatibility it is not worth the cost of continued upgrading. But now it looks as though I'll not be incurring that expense until at least 2013, if then. Well, did anyone important get this message? Perhaps I should expand this more and send it to the shareholdersAnonymous
August 24, 2009
@Ron: VB5, Pascal, Fortran and Delphi have something in commmon - almost no practical use or significance in the industry today. Pascal was once a good candidate to teach programming (for beginners). I don't think VB5 or Fortran code is readable or easy to maintain for modern day large applications. Pointers have faded away in recent times for popular languages like VB.NET and C# (C# does support limited features of pointers in unsafe mode). Don't see that as a feature everyone would use. The beauty of these languages is simplicity and managed code. Pointers are nightmare to debug, read and wreck havoc if not used properly. Why don't you use C++ if you are so fond of pointers? What is it that you are trying to achieve/accomplish with pointers anyway?Anonymous
August 24, 2009
MSDN seems to have uniformly poor documentation now. contrast this with about 3 years ago when all the win32 SDK stuff you would find was really well documented and excellent with proper listing of error values, sample code for each api and so on. Now, you dont even have proper explanation or listing of errors/exceptions for gcnew or how you would define a delegate function System::Action<T> or System::Predicate<T> for the ForEach function of collection classes and the list just goes on and on. Its not an isolated case and the whole thing is poor quality.Anonymous
August 25, 2009
The VS2010 page [1] says "Make sure your MSDN Premium subscription is current, and you'll get Visual Studio 2010 at no additional cost." Is this a mistake, or does this mean that MSDN Professional subscribers will not get Visual Studio 2010 Professional, or will have to pay extra for it? [1] http://www.microsoft.com/visualstudio/en-us/products/2010/default.mspxAnonymous
August 25, 2009
@Daniel, so you look at connect and determine "no one" wants dynamic, huh? What did you use as a query? Did you look for COM interop? Dynamic language interop? Simplified reflection? I'm not going to bother looking, because even if there is no results, this still proves nothing. Connect is mostly used for reporting bugs, not for making feature requests, and even then there are far more reports made through different channels. Connect is a very small, VERY SMALL part of the communication made between Microsoft and customers. Maybe YOU don't want dynamic... and I know there's a crowd of folks who don't (mostly for misguided reasons), but there's also a huge number of us that are saying "it's about darn time". Dynamic simplifies a lot of things that we do on a daily basis, and it's more than welcome in C#.Anonymous
August 25, 2009
The comment has been removedAnonymous
August 25, 2009
The comment has been removedAnonymous
August 25, 2009
Ron, the audience for C# are usually not system or low-level programmers. Most of the methods, properties and features provided by the .NET Framework can easily help developers achieve the same end goal without having to deal with messy pointers. Why would one want to deal with pointers if .NET provides really easy (easier than pointers) to use classes for File handling and representing data structures? One cannot go wrong with this approach vs. pointers for almost all requirements. Pointers also compromise readability of code. As powerful as pointers may be, users of these programming languages don't care much about pointers as long as the business goals are met without having to worry about debugging, memory issues, core dump exceptions and fatal errors! Andres Hejlsberg can give you more insight! :) Good luck!Anonymous
August 25, 2009
Wake up people, these enhancements are put it to try to convince internal departments at Microsoft to embrace this technology. The office and Windows 7 teams at Microsoft will not touch the majority of this new technology like WPF and there are good reasons for it. It is too clunky to use and they have their own libraries/stacks that are stable and work much better. The sooner everyone realizes Microsoft caresless about your requests and what is needed in the field the better. Microsoft is changing paradigms faster then Obama is spending money and none of the new paradigms are any good. Quit wasting your time on these blogs and do something productive like code and make money. If you are smart you will still be using Visual Studio 2005 and quit being free beta testers for Microsoft.Anonymous
August 27, 2009
Thanks. It was really worth information..Anonymous
August 30, 2009
Please add exception filters to C#. It works in VB so it should work in C# also. I really miss that feature, and I'm confident that I'm not alone in this...Anonymous
September 01, 2009
Hi Vijay, My name is Marzena Makuta and I manage the Visual C++ documentation team. We own one of the topics you refer to, gcnew, and also anything that appears under the Visual C++ node in MSDN. Our team is very interested in making sure our customers find all the information that they need. I’d like to get some more information from you to better understand what additional content you were looking for in this topic. Similarly, I am very interested in hearing specifics about what you would like to see in our other topics that you would find more helpful. Please feel free to email me at marzenam@microsoft.com, and I’ll be happy to hear how we can improve. Cheers, MarzenaAnonymous
September 20, 2009
What is wrong with var employeesToGiveBonus = from e in EmployeeCollection where e.Salary > 100000 select e; session.Update(employeesToGiveBonus, e => e.Bonus = 100); (Where session is something specific to the tech that also provides the LINQ provider, for example, NHibernate ISession.) This way each LINQ provider can choose what to support or not. For many LINQ providers update or delete doesn't make sense. I think LINQ should be kept Query only, and not be tied down to database specific scenarios.Anonymous
October 25, 2009
hi, its interesting to see the new enhancements of vb and c# in vs 2010. if you want more on this have a look at this link. http://www.vs-2010.com/vs2010/post/vs-2010-overview-vb-and-csharp-language.aspxAnonymous
December 22, 2009
First of all. Thanks very much for your useful post. I just came across your blog and wanted to drop you a note telling you how impressed I was with the information you have posted here. Please let me introduce you some info related to this post and I hope that it is useful for community. There is a good C# resource site, Have alook http://CSharpTalk.com Thanks again Rahul