I'm extremely new to programming. Just above school level. I created a project using EF Model First only to realize after I cannot get it to use SimpleMembership for Login, etc.
I wanted to try and solve this problem whilst remaining model-first as I asked here: https://stackoverflow.com/questions/36552439/could-someone-explain-this-code-to-me-ef-model-first-mvc
However, due to lack of response I'm considering just migrating the project to code first. I know that it is possible but I've been following tutorials online to no avail.
Could someone please explain to me how to properly move to code first. I'm even willing to recreate the program if necessary as long as it does not take too long.
I'd really appreciate some help.
Thanks
This really has been answered here.
I think you should really consider moving to ASP.NET Identity Membership, it's much more robust and has plenty of nice features without being difficult to manage. This is a really nice tutorial.
As for EF Code/Model first, you're thinking of them as something that defines your project; but really, they define a database CONTEXT. In other words, you can use both! Now don't get crazy, things can get sloppy quickly. But there is nothing that stops you from pulling in an existing set of tables and building models from them, but then adding another context to promote your classes into a database.
If you think of it as "switching" your project, you're getting it backward. And regardless, to get your models and database to sync, you need to either migrate your models or import your tables into EF. But it's a specific action you take, nothing happens magically. You COULD write your classes to perfectly mirror your database, create your EF models, and everything would work without you doing any direct connection (though you'd have a bit of a migraine afterward).
So don't worry about moving from one to the other. Just add a new context if you have a specific need to manage classes across different contexts.
But seriously, look at ASP.NET Identity to make all these problems go away...
Related
I was reading this answer in trying to understand how to work with multiple developers working on multiple branches of a project. My first reflex was to want Jenkins to run a separate build for each branch, but as I understand it, this is a bad way to approach the problem.
Now, I see how having very small features or parts of features which get merged back into the main branch often is the preferred way to go, but I can't quite wrap my head around what happens when a project goes through a very large architectural change.
Say I have a web project written in AngularJS and the team decides that for the future of the project, it needs to be moved over to using ReactJS instead. Said current project would have a reasonable number of features already implemented and tested. At this point, I can't imagine any smaller increment for the new "feature" of using ReactJS other than having it be on part with the current state of the project, meaning every test currently passing should still pass once it's done. Anything else would mean a regression for the project and I know of very few clients who would be ok with this.However, that's hardly going to be the case until the switch is almost 100% done, which will not be a small amount of work.
I might not understand the concept perfectly, but I don't see feature toggles working here (especially if the move to ReactJS requires we modify, say, the Gruntfile since that will inevitably break things a lot). Does the team doing the migration simply needs to tell the rest of the team not to touch the project until they say it's ok? That seems like a weird solution to me.
So I'll admit, I'm at a loss as to what the proper workflow would be here. Any input would be appreciated as our development process is something I constantly try and make better, even with my limited experience in the field.
We have a website application that stores data and pictures for a specific customer. We are about to release the same application for use by another customer. The second application will eventually be customized for the second customer. Eventually we hope to have several customers using their own versions of the application.
We are using ASP.NET in Visual Studio 2012. Should we:
clone the existing application and maintain separate code bases?
add a project to the existing solution for the new customer?
We have searched for an answer to but this seems to be a rare situation.
Thanks.
I dont think its rare at all. SAP and Maximo use this a a businiess model. Same core but each package customized to the clients specifications. I have done this (on a much much smaller scale) with some of the programs that we have.
We always start a new project rather than just copy the old. No telling what is in the old one that references the old client. Sort of embarasing when an About window that you forgot about is for someone elses company.
All the code, forms, reports that are customizeable should be in the project for that customer. All of the code, forms, reports that are standard should be in a library.
It really depends on the scope of the application. I've had to do this internally with the company I'm working for; I wrote one solution for one company, then the sister company found out and wanted the same and had to implement it there.
I had a fairly small project to work on, so it was easy to make it universal (while also keeping things rooting from the same code base). All i did was:
break out the unique setting [page title?] using appSettings or similar.
add a new configuration to your solution. Then take advantage of the *.config migrations to:
set connectionStrings
specify appSettings values
When it comes to unique business logic, I had the luxury of using the *.config migrations (most of the data I gathered came from WCF endpoints of services local to the company)--so I lucked out. However, you could make generic interfaces within the app then break out implementation for each company in to separate libraries.
We are currently using Jira 5.1.6 with GreenHopper 6.0.5. We have a lot of projects, probably about a dozen total but only a few that are actively worked on at a time, with the rest being there for occasional bugfixes or other tasks. The 4–5 developers in our company are likely to be working on a couple projects at once (some working on just one, some working on maintenance on several, and it somewhat varying who's working on what depending on the business priorities).
So, GreenHopper seems set up from a very project-centric view. I can set up a Rapid Scrum Board for a project, and make Sprints within it of work to do for that project. This can give the business a good view of work into that project. Potentially, one can also make a Board for all of the projects (since GreenHopper 6 added that), and make a kind of "global sprint" across everything. If we were to have this kind of global sprint, all of the project owners would need to work at once on figuring out what should get done over the next couple weeks, which might be workable, but seems a bit tricky and would require a lot of coordination.
What I think we want is some kind of "resource view" or something, so that project owners could set up their tasks in their sprints, but there's some sort of view for each developer to tell them what task they should be working on next no matter which project's sprint it's in, and some way for our manager to allocate our time across the projects. So, I might be scheduled to work, for example, 20 hours a week on project A, 10 on project B, and 10 on maintenance of other projects, and then project owners making sprints could see how much time they had allocated, and I as a developer would see some kind of unified view of my upcoming tasks, so that I would know what I should be working on next and what's coming soon. I don't know if that description is exactly what we want, but I think we want something along those lines, and it seems like we can't be the only place that wants some sort of project-based view as well as a resource-based view.
The thoughts I've had of how we might approach this from my exploration of GreenHopper so far are:
Create those "global" sprints I mentioned, and work as a department at the beginning of each sprint to try to schedule what we'll all be doing. Projects can get a look at their particular piece of the sprint using a Quick Filter or somesuch, and we just have to deal with coordinating those sprints.
Use the "Parallel Sprints" feature on an all-projects Board, and have each developer create their own sprints of the tasks they have coming up. This helps with getting a resource-based view, but is probably tough for projects to figure out status of things, and definitely feels like squeezing GreenHopper into a space that it really doesn't want to go.
Create a board for each project of the things to be coming up for each project, so each project gets its own Sprints and we get the project-based view of things, and just have each developer track themselves which projects' sprints they should be getting tasks from. Basically, just GreenHopper isn't the tool for a resource-based view, so don't even bother, and trust our developers and our manager to look across all these projects for what tasks to work from rather than trying to do it all in one place.
None of those seem great, though I'm sure we could make do with any of them. But I keep on coming back to that it doesn't feel like we're doing something bizarre or unique to us, and we would have thought that since Jira/GreenHopper was an industry-standard agile tool that it'd be easier to use it for what we're trying to do. Are we doing something crazy? I think we'd be fine with changing our process to use standard practices if there's a standard way of doing Agile across multiple projects out there. Is there some GreenHopper setting or report or something somewhere I've missed? Is there some other Jira plugin that we should be using instead of or in addition to GreenHopper? Do other teams out there use one of the above approaches and can give advice on whether or not it's a good idea?
Any help would be appreciated. Thank you.
"... seems a bit tricky and would require a lot of coordination." Yup, sounds like project management to me.
I'd create boards for each product that gets released on its own schedule. I'd also create a query to show each user the issues assigned to them sorted by Sprint so they can see what work is on their plate. The issues will be across multiple boards and sprints.
I do wish that GH helped with resource allocation more, including totaling up the time allocated in the filter in the previous paragraph. At the moment I end up exporting the results of the filter to Excel and using that to sum up totals by resource.
I asked this question in perhaps the more appropriate place, on the Atlassian forum:
https://answers.atlassian.com/questions/99020/how-do-i-use-greenhopper-to-manage-developers-across-multiple-projects
And I think the answer there from them was very good. I created a board for each project, limited to its project and used for creating that project's sprints, and the developers use an "All Projects" board to see all of the sprints that they're a part of.
Doesn't handle resource allocation wonderfully, as mdoar states, but it does seem to be using the tool the best way that it can be for this for now.
I'm fairly new with EF and got myself rather confused about what's going on with my solution.
I'm in the situation where my code appears to be working however the changes aren't being written to the database that I would expect.
I'm using Web Developer 2010 and SQL 2008, code first approach but choosing to make my own changes in the database and manually ensure my classes match correctly.
Things seemed ok until I came across an error where the db hash wasn't what entity framework was expecting, so I looked at modelBuilder.Conventions.Remove(); which wasn't available - it seems that's not around in the later versions. So, I figured if the later versions doesn't do this check, I'll go ahead and remove my reference to EF 4 and put the 4.3 dll in it's place. I think I also ended up deleting and renaming my database. That didn't work, so I followed up on something I found on Scott Gu's blog about naming your dbContext the same as the database, which seemed to help.
However I'm now getting the most bizarre scenario. My code is running, the data is saving, but it's not saving to my database. In fact I'm running a profile trace on the db and it doesn't even seem to be trying to connect. I can change my connection string to something invalid too, but my code will happily run, storing the data #somewhere#
Any ideas what's going on? Might it be using a local database or cache that I'm unaware of? Should I just start my small project again and pretend this never happened? That'd be the professional approach, right?
I would suggest to use Database first approach, if you have your Database set, or want to have maximum control over database.
When you use the Code First EF approach and just point to ./SQLEXPRESS, EF nicely builds your tables for you, defines all the fields, etc.
But it doesn't seem to work that way when you direct your connection string to add an .MDF file in /App_Data instead. Is that working as intended? The tutorials I'm finding on this, such as this one, show the tables in the .MDF being created by hand.
But I have not seen any documentation anywhere plainly state that Code First EF will build your tables one way but not the other, so I'm frankly just confused. Any illumination or advice on this would be greatly appreciated!
ETA: Okay, I see that this tutorial I linked is for the database-first approach, not code-first. In other places I'm reading that EF should, in theory, populate an App_Data/.mdf file the same way. But it still won't for me; if I give it an empty .mdf file to work with it refuses to add tables; if I don't give it an empty .mdf it tries to build one in my C:/Users/ directory.