none
Upgrade to VS2013 has broken my solution RRS feed

  • Question

  • I've just upgraded from VS2010 Pro to VS2013 Pro, and I have a major problem which is I believe related to EF and the ObjectContext/DbContext scenario.

    I've developed a Silverlight application based on the (now defunct!) Silverlight Business Application template. I understand that RIA Services is being "Open-Sourced" and that is why this template and the associated DomainService template have been removed, but I was at least hoping that I could still build my application - but I can't.

    My Model.edmx inherits from ObjectContext and creates classes inheriting from EntityObjects. I understand that "since VS2012" they should be inheriting from DbContext instead? But how do I make them do this?

    The first thing I had to do (or maybe I should say "the first thing I did") was Import my model namespace into my domainservice source file. That didn't decrease my errorcount (because it's currently at the max of 102 in 2 projects), but did change the nature of all the errors to something similar to:

    "Value of type namespace.datatype cannot be converted to namespace.modelnamespace.datatype"

    This is being produced by all the functions in the domain service file defined as eg IQueryable(Of Something) but which return Me.ObjectContext.Somethings. The two are no longer the same - ie the Function declarations ALL return "Something" but the return statements within these functions ALL return sets of "ObjectContext.Something".

    I CAN manually edit every single function (and I've done this on a smaller project to prove the point), to force the declaration statement to be the same as the return statements, but I'm pretty sure that's not the best way to fix this, and also I would have nearly 800 lines of code to change ...

    I can't be the only person to be suffering from this! Apart from any pointers as to how I should go about fixing my immediate problem of having a large broken heap of useless code, are there a set of instructions anywhere as to how we are now supposed to, for example, add a table to the database, update the model from the database, and then utilise the generated datatypes and CRUD routines?? I could just push the button in VS2010 and it would all "happen". If the worst came to worst, which it occasionally did, I could also delete the model, domainservice and metadata classes, add a new model and domain service and push the button again ... and everything would be fine. No more, sadly ...

    Ade

    Thursday, November 7, 2013 11:43 AM

Answers

  • Here is a permanent workaround:

    1. In the properties of the project, clear the Root Namespace.
    2. Right click on the EDMX file itself and in the properties set the Custom Tool Namespace to the previous Root Namespace
    3. Open the EDMX and in the properties set the namespace to the previous root namespace.
    4. Open your DomainService and any other class files and add a Namespace to them with the previous root namespace to each of them.

    The should result in working code. The custom tool namespace will make sure that VS2010 generates the code with the namespace in it, the namespace inside the EDMX will make sure that VS2012 generates the code with the namespace in it. This does mean that any file you add to that project will need the namespaces added manually.


    http://www.openriaservices.net | RIA Services and MVVM http://bit.ly/pgL97k

    Wednesday, November 20, 2013 2:48 PM

All replies

  • Hello,

    For this issue, my suggestion is that we should delete the old model and create a new model which is inherited from DbContext.

    Since the program is from VS2010 and it used ObjectContext, we cannot use the old codes directly because they use the ObjectContext.

    So we need to do a translation to translate the DbContext to ObjectContext so that we could use the original codes again.

    The translation codes would be like below:

    using (DataBaseFirstDBEntities db = new DataBaseFirstDBEntities())
    
                {
    
                    ObjectContext objectContext = ((IObjectContextAdapter)db).ObjectContext;
    
                }
    

    If I have misunderstood, please let me know.

    Regards.


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Friday, November 8, 2013 2:44 AM
    Moderator
  • Thanks for your reply, which actually moved me a step further down a path ... it doesn't feel like quite the right path but it's something new at least.
     
    When I deleted and regenerated the model in VS2013, it didn't generate ANY code in the designer file, but it DID put some comments in there which pointed out that if you open the edmx and click on the designer background, there is a property in the Properties window called "Code Generation Strategy". By default it's set to T4, but it can be changed to "Legacy ObjectContext"!
     
    So I did exactly that and rebuilt the project. Bizarrely that caused the designer file to be filled with code based on the DbContext NOT the ObjectContext. However, when I did an "Update Model From Database" it changed it to ObjectContext, and now I have no errors in my .Web project!
     
    However, I still have 102 errors in my client project. This is because it has not recreated the "generated" code file which communicates the datatypes to the client (....Web.g.vb), This remains unmodified and still has all the classes inheriting form an unknown "Entity" object. In VS2010 this shows as System.ServiceModel.DomainServices.Client.Entity, but as we know, the DomainServices have been removed from VS2013.
     
    How do the generated classes get passed to the client in the new world of VS2013?
     
    I really appreciate your help - thanks a lot.
     
    Ade
    Friday, November 8, 2013 1:02 PM
  • >>When I deleted and regenerated the model in VS2013, it didn't generate ANY code in the designer file, but it DID put some comments in there which pointed out that if you open the edmx and click on the designer background, there is a property in the Properties window called "Code Generation Strategy". By default it's set to T4, but it can be changed to "Legacy ObjectContext"!

    Yeah, this is another way to use the ObjectContext. It will create all the entity class which inherent from ObjectContext.

    >> However, I still have 102 errors in my client project. This is because it has not recreated the "generated" code file which communicates the datatypes to the client (....Web.g.vb), This remains unmodified and still has all the classes inheriting form an unknown "Entity" object. In VS2010 this shows as System.ServiceModel.DomainServices.Client.Entity, but as we know, the DomainServices have been removed from VS2013.

    Since the web side has been changed, in my opinion, the client side should be changed.

    And for this issue, I recommend you to post this to the corresponding forum:

    http://social.msdn.microsoft.com/Forums/en-US/home?forum=silverlightwcf

    Because I think this issue is more regarding WCF RIA Services.

    Thanks for your understanding.


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Monday, November 11, 2013 6:40 AM
    Moderator
  • OK, well after a bit of hair-tearing, I'm back, with the following response from Colin Blair in the RIA services forum, who was VERY helpful:

    You aren't crazy, you just failed to mention before that you were using VB. Trying it with VB I replicated the error.

    Unfortunately, that means I need to send you back to the EF guys as this is not a RIA Services issue. The namespace of the generated code in VS2010 does not match the namespace of the generated code in VS2013 if you are using VB. 

    The key link difference is actually right below the line you pointed out. In my code example, the VS2010 code had no namespace link, the VS2013 code does. My guess is whoever wrote the new template doesn't understand how VB.NET namespaces work.

    The simple way to reproduce this is to build a new Silverlight Business Application in VS2010. Add an ADO .NET Entity Data Model to the .Web project via the Installed Templates/Visual Basic/Data path, and link it to a couple of tables in the AdventureWorks2012 database. Then add a Domain Service Class to the .Web project via the Installed Templates/Visual Basic/Web path, click the "Enable Editing" checkbox for each of the selected items in the dialogue, and then build the project. Works fine. 

    Now open this solution in VS2013, it will upgrade OK, but it will not compile, since as mentioned before, the namespaces in the model designer are confused.

    What I find very strange is that it WILL upgrade and compile in VS2012, and if you then upgrade the VS2012 solution in VS2013, it works (after a minor tussle with the default forms authentication). The only difference between the VS2010 model.designer.vb and the VS2012 model.designer.vb is the contents of the EdmSchemaAttribute Tag. After upgrading the VS2012 project to VS2013, the model.designer.vb remains unchanged, whereas if you upgrade direct from 2010 to 2013 it gets trashed.

    Any ideas would be very welcome, but having to run 3 versions of Visual Studio side by side is a step too far!

    Ade

    Monday, November 18, 2013 10:25 PM
  • >>What I find very strange is that it WILL upgrade and compile in VS2012

    Does it mean that if you update the program from VS2010 to VS2012, it will change the ObjectContetxt to DbContext but to VS2013 it will not?


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Tuesday, November 19, 2013 9:45 AM
    Moderator
  • Hi Fred

    No, it stays as ObjectContext in VS2012, and then through to VS2013.

    As I said, there is only ONE line of difference between the VS2010 Model.designer.vb code and the VS2012 Model.designer.vb, and that is as follows:

    VS2010:

    <Assembly: EdmSchemaAttribute("5ec6c251-b9ac-463d-9faa-9bb52fcfebc1")>

    VS2012:  

    <Assembly: EdmSchemaAttribute("733aa46c-436c-4303-9e0d-695f5f82f10f")>

    Both are inheriting from ObjectContext. When the VS2012 Model.designer.vb is "upgraded"/generated by VS2013, it remains completely unchanged. But when the VS2010 Model.designer.vb is "upgraded"/generated by VS2013 it is made unusable due to the namespaces getting confused as mentioned in my original post - all function return statements return datatypes which are not the same as the function declaration statements.

    Thanks for your help - I really appreciate it.

    Ade

    Tuesday, November 19, 2013 10:32 AM
  • When I reproduced the problem, I found that the problem was with the namespace, not the EdmSchemaAttribute. Creating a new project in VS2010 and adding an EDMX with the default configuration other than adding the connection information, on VS2010 the generated code from the EDMX has no namespace line because it is using the default namespace of the project. This is important because in VB the default namespace of the project is the root namespace for all code files in the project. That is one of the main differences between C# and VB.NET.

    If you then open that solution in VS2013 and compile, the generated code has a Namespace line at the top so all of the generated code in VS2013 has a different namespace then the generated code on VS2010. Switching back and forth between VS2010 and VS2013 causes the namespace line to appear in VS2013 and disappear in VS2010.


    http://www.openriaservices.net | RIA Services and MVVM http://bit.ly/pgL97k


    Tuesday, November 19, 2013 1:50 PM
  • Just double-checking here (and via my phone which may be tricky), Colin, did you mean VS2013 where you have VS 2012 in your above comment? I only see the Namespace line when going direct from 2010 to 2013. When going from 2010 to 2012 I get no namespace line; WinMerge shows the only difference is the edmschemaattribute value. What I find especially puzzling is that VS2013 will do nothing 'insppropriate' if it starts from the file generated by VS2012. This us what makes me feel that that edmschemaattribute must be important! Ade
    Tuesday, November 19, 2013 2:56 PM
  • Correct, I meant 2013 and fixed it above. The EdmSchemaAttribute is just getting a different GUID, that doesn't matter because the GUID doesn't mean anything other than being unique for that model in the assembly.

    When you go from VS2012 to VS2013, 2013 is accepting the generated code as already being up to date. If you right click on the EDMX and "Run Custom Tool". or just open the EDMX and save it, you will see that the Namespace line shows up and compilation will break again.


    http://www.openriaservices.net | RIA Services and MVVM http://bit.ly/pgL97k

    Tuesday, November 19, 2013 3:26 PM
  • Ahhhhhhh ...... OK! It's all beginning to become slightly clearer. Still not entirely sure what leads VS2013 to believe that the code is up-to-date?
    Tuesday, November 19, 2013 3:32 PM
  • Fred, I see that you have proposed this as an "Answer" to my problem. I'm not sure that I understand the procedure here ... yes, this is an explanation of why my problem is occurring, but is it an answer to my problem? I would say No it isn't. I accept that the only way further significant progress can be made is for the Microsoft Entity Framework team to fix the bug, so if there was a statement to that effect then I guess I would accept that as an answer! In the meantime my code is damaged and although I can temporarily fix it by making hundreds of edits, I have to redo those edits every time the model file gets regenerated. So, if someone says "we're working on fixing this bug" and "this is the timescale", then I'll be happy to mark it as an answer. Ade
    Wednesday, November 20, 2013 8:26 AM
  • Hi pencerdd,

    It is my mistake, I am really sorry for this.

    If this issue is urgent, you can submit your feedback regarding this issue on website below.

    https://connect.microsoft.com/VisualStudio

    Regards.


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.


    Wednesday, November 20, 2013 8:39 AM
    Moderator
  • Here is a permanent workaround:

    1. In the properties of the project, clear the Root Namespace.
    2. Right click on the EDMX file itself and in the properties set the Custom Tool Namespace to the previous Root Namespace
    3. Open the EDMX and in the properties set the namespace to the previous root namespace.
    4. Open your DomainService and any other class files and add a Namespace to them with the previous root namespace to each of them.

    The should result in working code. The custom tool namespace will make sure that VS2010 generates the code with the namespace in it, the namespace inside the EDMX will make sure that VS2012 generates the code with the namespace in it. This does mean that any file you add to that project will need the namespaces added manually.


    http://www.openriaservices.net | RIA Services and MVVM http://bit.ly/pgL97k

    Wednesday, November 20, 2013 2:48 PM
  • Hello pencerdd,

    I post this to make sure that whether the workaround provided by Colin works for you.

    I fisrt mark Colins reply an answer and if this does not work for you, please unmark it.

    Thanks for your understanding. 


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Tuesday, November 26, 2013 7:41 AM
    Moderator