I have 2 VS solutions.
The first solution has a WebUI project in .Net 4.5.2 and a Domain project also in .Net 4.5.2. The WebUI depends on the Domain and holds a reference to it. The Domain builds first. Everything works.
The second solution has a WebUI project in .Net 4.6. I "added" the Domain project from the first solution here (by clicking right mouse on my solution name --> Add --> Existing project).
I added a reference here also and the Domain builds before the WebUI just as in my first solution. Things work correct, for example, I can create a viewmodel in my WebUI and reference to a domain class. I can also acces the domain classes after using an import statement in my controllers. See second pic where I use the person class and contact class. This all works fine. I have some issues however.
In the WebUi's when I want to generate a mvc5 controller using entity framework in my first solution I see in the model class dropdown list my domain entities.
However, I don't see these entities(Domain.DbEntities) in my second solution in the dropdown, which I find very strange since I can acces the domain entities from whitin code-files which you can see in de background(i.e. 'person' and 'contact' in my EditPerson(int id) action method
Anybody an idea why?
Maybe the different framework version is the problem.
Have you build the project already?
See also: Add Controller Model Classes not shown
Related
I've create two MVC and Web API .Net Core projects in one solution, in first project i've added model Phone and DataContext for it, made migration and update-database. In second project i've added equals connectionstring,model and DataContext, but when i try make the update-database i get the next error:
There is already an object named 'Phones' in the database.
Tell me please the right way how to configure database, datacontext and models in two projects to use one database ?
If you use two separate DbContexts, each with their own migrations, they'll consider the database to be theirs and reapply the changes that the other project already did, resulting in conflicts such as the one you observed.
Simply move the Entity Framework code into a shared class library and reference that library from both implementing projects, so all state about the database is shared.
I would like to explain the exact scenario as follow:
There are two CRM instances - one is development (or Dev), and the other is sandbox (or UAT).
I did some changes in the Main form of Opportunity entity (added new fields, and a few more UI changes) in a custom solution in Dev instance. Exported the solution as Managed one, and imported in the UAT instance.
At this stage, Opportunity form appears same in both Dev and UAT instances.
I have created a new solution in Dev instance, and added Opportunity entity again. Did some changes in the Main form of Opportunity entity again by removing some UI elements, and by adding some new fields.
Exported the solution as Managed one, and imported in the UAT instance.
After publishing the changes, I can see that the Main form of Opportunity entity now contains all newly added fields, but also the fields which I had deleted in the Dev instance.
In summary, it didn't delete those fields from the UI of Main form, but just added the new ones.
Could any one please help me sorting out this issue? What could be the possible reason here?
It is by design that changes to forms are merged when importing multiple managed solutions. The MSDN article Understand how managed solutions are merged is a good read for understanding this:
When a solution is packaged as a managed solution the form definitions
stored in FormXML are compared to the original FormXML and only the
differences are included in the managed solution. When the managed
solution is installed in a new organization, the form customization
differences are then merged with the FormXML for the existing form to
create a new form definition. This new form definition is what the
user sees and what a system customizer can modify.
I have my API controllers in an extra project separate from the console project where Owin is hosted.
The requests to the controller work, but how is that magic done?
From where does my console project know the project where my controllers are?
Enumerate all added references and check for types inheriting from ApiController?
I might disappoint you, but there should not be any magic in there. ;-)
I see two possibilities how your console project could know about the assembly where your controllers are:
You are using a Custom Assemblies Resolver (like this one here)
You are referring something in the controllers' assembly which is causing the assembly to be loaded
I gave a try to the second option and it works like a charm:
I've an existing MVC3 project that implements a certain functionality, this project has it's own views, and a separate Database.
now I'm required to use the same functionality inside one of my orchard project,so I thought that I can host this solution in somewhere and view it inside an iframe or something.
Am I thinking right?,
is this the correct step to take in order to achieve this requirement inside Orchard?
to make it more clear, all I need to do is to view this solution and interact with it's controls and views from a hosting page inside orchard, and the subsequent requests should be handled by my solution in order to hit it's own data store and get back with the requested data in order to be displayed to the user.
any help would be appreciated.
Update:
thanks for Bertrand Le Roy for his answer, I can now view my solution inside my
orchard website.
I came in to one more HUGE problem, which is that my application can no longer connect to my external database.
I've a DB that is hosted in some where else, and I'm using EntityFramework to deal with it.
the problem is that if I put the connection string inside my module web.config, or main orchard web.config, I run into several types of errors like:
"System.Reflection.TargetException: Object does not match target type."
or
"System.Data.MetadataException: Unable to load the specified metadata resource."
My question is: How could I pass my connectionstring correctly to my solution, assuming that I'm using Entity framework as my ORM.
Many thanks.
You will need to put it into a module.
You will have to move route definitions to a Routes.cs file (look at any existing such file for examples).
You will also need, in order to access your data store, to opt out of the ambient Orchard transaction around the data access code (using (var scope = new TransactionScope(TransactionScopeOption.Suppress))).
If you are using dependency injection, you may have some work to move that to the Autofac-based way of doing things in Orchard.
If you want your work to appear seamlessly in the Orchard admin, you may want to decorate your admin controllers with the Admin attribute. If you want your front-end to use the current theme, you'll have to add Themed attributes and maybe refactor your views so that they only emit HTML for the content zone instead of for the whole page.
Add a manifest (module.txt) to your module folder and you should be good to go.
I am currently using EF 4 with my ASP.NET Website to access a MySql database. This works fine. However I now want another Web Site project to access the same entities. How do I set this up?
I can't just reference the original website as it's a Web Site, not a Web Application. So presumably, I need to put the Entity Data Model in its own project and compile to a DLL. But...
Which project type?
Do I just cut and paste the DataModel.edmx and DataModel.Designer.cs, compile and add a reference in both websites? What about namespaces?
Where do I put the connection string? At the moment it's in my project's Web.config.
I really have no idea where to begin - I've just followed tutorials to get EF working up to now! I'd really appreciate step-by-step instructions if anyone has time. Thanks.
The model should be placed in a new class library project. My preference would be to recreate the model at this point based on the existing model. For the namespace I like to use {CompanyName}.DataAccess. Remove the old model from your web site project, add a reference to the new class library project and build the web site project. The website project will break in many places, but it should be a simple matter of changing the namespace to the new data access assembly. I prefer this method as to cut/paste because now you have nice clean namespaces. Be careful of any places you may have strings with entity names in them, like if you were using Include (if you are using EF 4 and lazy loading, this should not be a problem). Leave the connection string in web.config for both of the web site projects. When you create the model in the class library, it will add a connection string in app.config. That is OK, it is just there so the model knows how to connect to the database when you refresh it.