I have the hardest time creating an WebForms RDLC report with my business objects, in Visual Studio 2010. I am using the designer to build my report.
In the Report Data View of VS2010 I select New/Dataset... Strange enough, the Data Source Configuration Wizard immediately pops up, covering the Dataset Properties dialog.
When I cancel the Wizard, I am able to manipulate the Dataset Properties dialog somewhat, but none of my business objects does show up. Actually, nothing selectable shows up at all.
What do I need to have my business object selectable?
Note: Earlier in the project, this once worked. I must have changed something, but what?
I have read this question, but my Dataset is in the same project, on the ASPX-Page's code behind file. I have set it up like so:
public IEnumerable<MyDto> Getxy() {
return new List<MyDto>(); //TODO later use real data.
}
I have also read this one but my object already matches what's suggested there. It is a really simple POCO DTO's with no constructor (which makes it automatically have a public parameterless constructor)
Related
I have two Entity Data models within a MVC3 project A and B.
I have recently added the new entity data model B to deal with some new functionality, the issue is that now the existing code has stopped working and I am getting the following error when trying to access code within entity model A.
The error message is:
Could not find the conceptual model type 'project.models.Bclass'
I do not understand why it is this new functionality has affected the current code seeing as entity model A has not change in any way. And functionality B is in a separate class and does not interfere with model A.
When the new code is removed from the project and entity model B is excluded then the code works as it should.
Here is some of the stacktrace from the error:
Exception : Could not find the conceptual model type for 'Project1.Models.CrossSession'.
Application Class - method : System.Data.Metadata.Edm.MetadataWorkspace -- GetEdmSpaceType
User : temp.user
Url : http://localhost/project1/auth/message
Stacktrace : at System.Data.Metadata.Edm.MetadataWorkspace.GetEdmSpaceType(StructuralType objectSpaceType)
at System.Data.Entity.Internal.InternalContext.UpdateEntitySetMappings()
at System.Data.Entity.Internal.InternalContext.TryUpdateEntitySetMappingsForType(Type entityType)
at System.Data.Entity.Internal.InternalContext.GetEntitySetAndBaseTypeForType(Type entityType)
at System.Data.Entity.Internal.Linq.InternalSet`1.Initialize()
at System.Data.Entity.Internal.Linq.InternalSet`1.get_InternalContext()
Solution found. It appears in some cases (randomly) there is a mix up in the code generated by the entity framework. This is apparently a known bug and a fix should be coming in future releases. In the mean time the way around this is to move the efm to a separate class within the solution.
One possible explanation is that if you use the database first approach and forget to add the Entity classes, you will get this error.
i.e. (from the guide linked below)
Right click on the model’s designer surface.
From the context menu, choose Add Code Generation Item.
In the Add New Item dialog that opens, select Data from the list of installed templates types on the left.
Choose the ADO.NET DbContext Generator then click the Add
button.
I normally use Julie Lerman's guide; https://msdn.microsoft.com/en-us/library/jj206878(v=vs.113).aspx
Solved this by updating EntityFramework to the latest version (6.0)
http://nuget.org/packages/EntityFramework/.
After installing it regenerate the models and it will work ;)
I had the same problem with 2 different .edmx files in the same project.
For the first .edmx model I had used "Add Code Generation Item", for the second model I hadn't. The project was building correctly but throwing that exception on runtime.
I solved generating the .tt classes for the second .edmx model as well.
Well I just installed EF 4.1 and tried to combine DbContext with a EMDX - When I tried to pass back a view I got the same error - that's why I ended up here... I think the way around this is to separate the functionality out into separate asemblies in the solution...
This can also be resolved by generating the new edmx in visual studio 2010 so it matches the older ones... (And copying over the files it generates)
Using Visual Studio 12, the issue has still not been resolved. As an alternative workaround, I set up the second SQL data model using "old fashioned" Data Classes that pre-date entity models - they're still there and they still work. Use Add - New Item - (Data Category) - LINQ To SQL Classes, open the ServerExplorer, locate the server and database, then drag and drop it onto the data classes pane. Old school - but conveniently overcomes this highly inconvenient issue when the full functionality of entity models is not needed.
I removed the edmx models, removed the Entity package, re-install the entity 5.0 and works.
I was working with some legacy software and was not keen on upgrading EF. For me, the below setting on my newly added .edmx needed to be changed to match the .edmx that already existed in the project. My new one said "T4" and I changed it to "Legacy Object Context". I did have to delete the .tt templates that were generated previously in order to get it to build. Otherwise, the old generated files stay there and the new files are also there, causing "property already defined" errors. Thx to all the answers above that helped me figure this out!
(Properties panel, after clicking in the entity designer)
I'm using the Visual Studio 2010 Class Diagram designer and it does a nice job of showing relationships between a parent class and the classes that make up the properties of the parent. In the below sample, we can see that the IFoo interface has a property named Bar which is of type IBar.
However, if I add existing classes, interfaces, etc... that were created outside the designer it does not show the relationships. See sample below...
The code is all the same; and correct; but the representation on the design surface is different. For existing classes, is there a way to instruct the designer to make the correct links without having to manually recreate the items using the designer?
I wasn't able to find a way to do it for the whole diagram, but I did find a Property level context-menu item (e.g. Show as Association) which fixes it one Property at a time.
In my current job we are not allowed to use databinding. I’m currently using a code generator (ORM) to generate the data layer objects. In the past I usually generated a data source (from the object) and do a drag and drop to automatically add the controls (with the correct databinding to the WinForm).
Is there is a way to do something similar (programmatically) using Visual Studio?
I tried to use the a copy and paste approach (by analyzing the data of the control, in the clipboard, generated by VS), but unfortunately the format used by VS to serialize the control to the clipboard is binary (I was hoping that the format was XML because I can easy modify that). Other approaches I tried was generating the designer code using a code generator. Unfortunately this only works if I want to create a new form but it is, from a practical point, unworkable if you want to add new controls to an existing form.
Controls are just objects. Any properties you can set in the designer can be set in code as well. And event handlers are just delegates. You can build the entire GUI without using the designer at all -- just write the code. I've done this several times with dynamically-generated GUI elements.
Spend some time reading through the code that the Visual Studio designer generates, and you'll quickly see how to do the same things by hand.
I like Linq but find that once the designer has created my classes I have to modify them.
Then when I change my database and recreate my classes in the designer my changes get wiped.
For instance, let's say I have a class called Person.
I create this class, add some non database related methods to it (outside of Linq) and then create a database table with a similar name.
Linq will duplicate this class in the designer.cs file when I drag it in.
So I go and add the partial keyword to the class in that file or even change the class name Linq created.
As development proceeds, no doubt the database table changes and I have to redrag my tables into the designer.
Voila, my manual changes get wiped.
This is most annoying!
In fact, its unworkable to keep modifying code I have already modified.
Any suggestions?
Create a partial class for your context and make your changes there, the designer generated .cs files are recreated every time you click save.
We have an application that has to be flexible in how it displays it's main form to the user - depending on the user, the form should be slightly different, maybe an extra button here or there, or some other nuance. In order to stop writing code to explicitly remove or add controls etc, I turned to visual inheritance to solve the problem - in what I thought was a neat, clean and logical OO style - turns out that half the time inherited forms have a hard time rendering themeselves in VS for no good reason etc - and I get the feeling that developers and to some extent Microsoft have shunned the practice of Visual Inheritance - can you confirm this, am I missing something here?
Regards.
I thought they had more or less sorted the desktop designer issues in 2005.
Have you tried the usual culprits?
No abstract control types
No constructor arguments in any form
Initialisation moved to Form_Load as opposed to the Ctor
No controls in the same project as the usercontrol/form that they are put inside
Close all documents -> Clean -> Rebuild
Restart VS
I seemed to think that as long as you did all of the above it worked..... mostly.
I am studying towards the (admittedly soon-to-be-obsoleted) MCAD, and part of the WinForms element was Visual Inheritence.
I personally have had no major problems with it, however, there are considerations to take in to account.
For me, the main problem has always initialization.. You need to remember that the designer cannot/does not instantiate forms in the same way it does at run time (similarly, it cannot do this with web dev, which is why care is needed with custom control rendering).
Also, once a form is changed, a complete re-build of the project is required in order to propagate the changes to the form to the child forms that inherit from it.
I personally have seen no evidence to suggest that it has been "shunned". AFAIK, its still good practice to exercise code re-use where possible. Visual inheritance provides that.
May I suggest creating a new question with the actual problems you are having, with sample code? We can then look at it to see if we can get it working and explain why :)
I've seen some problems in VS2005 with this. They were mostly due to problems with construction of the forms-objects in the designer. There were issues with code that tried to access the database from the form-constructors etc.
You can debug issues like this by starting a second instance of visual studio and loading up the first instance in the debugger. If you set breakpoints in your code you can then debug what happens in the designers in the first instance.
Another problem I can remember was generics in form classes
public class MyForm<MyObject> : Form
this won't work
I often stumble upon such problems in Visual Studio. In many cases MSVS forms designer fails to render form correctly. Back in the days I worked with WinForms I had to do all kind of weird tricks to enable some complex scenarios. However I think that using visual inheritance is very beneficial and should not be thrown away regardless of MSVS designer bugs.
I think I've found a way how to avoid this problem.
Don't hook the Form_Load Event in your parent form, this will break the designer.
Also don't take the Default empty constructor away from Visual Studio in the Parent Form. If you want to have Dependency Injection, create another constructor.
Like this:
public ProductDetail()
{
InitializeComponent();
}
public ProductDetail(ISupplierController supplierController) : base()
{
InitializeComponent();
this.supplierController = supplierController;
}
You can then still do this from your inherited Form:
public NewProduct(ISupplierController supplierController)
: base(supplierController)
{
InitializeComponent();
}
This worked for me so far, and I had some weird designer issues too.
cheers, Daniel
Read this: http://cs.rthand.com/blogs/blog_with_righthand/archive/2005/11/10/186.aspx
AFAIK, there are still issues with Visual Inheritance and objects that rely on collections for the design elements, typically grid controls etc. I believe MS still have removed the possibility of changing f.ex. a GridView in an inherited form/usercontrol etc. But other controls like TextBox, Form, UserControl, Panel etc. should work as expected.
I've so far had no problem with VI using 3rd party grid controls myself, but you have to be careful, in particular, removing items from collections MUST be avoided.