I am trying to understand the concept of an MVC Area. I have read the following article: https://www.codeproject.com/Articles/714356/Areas-in-ASP-NET-MVC
In the linked article; there are areas for: Men; Women and Home. Where do you put the ASP.NET Identity classes? Homes?
Do you have any folders e.g. Controller; Model etc in the root folder? The root folder is the same folder as the Areas folder
Are areas used so that a large application can be worked on my multiple teams. For example, team 1 works on area 1 and team 2 works and area 2 and team x works on area x etc?
Say there are three teams. Is it possible for each team to create a new MVC project to work on. Then at deployment time the areas are combined to deploy as one web application
simply speaking areas are mvc project inside mvc project. You can use global ASP.NET Identity classes - in main mvc project or even configure for every area, but is it realy need to you?
You can have Controller; Model etc in the root folder in main mvc projects, also you can create it's inside every area. it depend from purpose. In most cases you will have them as in main as inside every area.
NO. areas used for Separation of the functional, creating something similar to modules. team must work with task< not with area. which task to work for team - it's jira or something similar. No relation to areas.
yes. it possible. but will be very difficult. for this purpose use version control and branches.
Related
I'm working on a web application with asp.net mvc 4 and I want to do a administration interface,but I want do it in other visual studio's project. So I don't how it works, the routing, how connect to the database from other project. I'd really appreciate any help.
Follow this steps.
Create one solution
Add two projects to the same solution
Point the web.config of the two projects to the same database
It doesn't have to be so complicated with routing, because each project belong to a different site and a different environment.
In my opinion you should create just want project and define a new area for the administration
I have a VS C# solution using two different MVC4 with SimpleMembership EF projects. Each project has it's own database schema etc. separate from the other. I have it setup so that project B can access project A's models, and do CRUD operations. However, when I try to create a new user (for example using Websecurity.CreateUserAndAccount)all of that work will occur on that project only, and only affecting the database of that given project. So the question is, how can I use Websecurity features in project B, but actually affect the database in project A? (ie, somehow tell my project B that for this Websecurity.Whatever call, actually update/insert etc. into project A's database instead). Trying to avoid having to create my own custom membership if possible.
Thanks in advance for your time!
This may have been asked before but i was not able to address my needs in all previous posts (I've been searching it for couple of hours). All posts are so specific to its special needs. (I've been writing projects for couple of years but a newbie to TFS)
My Need Is:
I have one common helper project under default collection. (simple helper class and functions which helps me to avoid rewriting everything)
I am trying to use this helper project in every tfs project under different collections.
What is the best scenario to use?
Default Collection
-- HelperProj
Collection 1
-- Project 1
-- Project 2
Collection 2
-- Project 3
-- Project 4
Thanks in advance
Onur
Here is a link that may help you with your needs. Take a look at the work-space mapping and branching features to achieve what you need.
Code Sharing in Team Foundation Server
Organizing Your Server with Team Project Collections
My advice would be to use a single project in a single collection unless you have a compelling reason not to.
The reason is that although TFS looks in many ways like one large file-system, there are some things that don't work very well across project and collection boundaries. In my experience putting code into different projects/collections only works cleanly if there isn't (and never will be) a dependency between the lumps of code, so you can work on a single project/collection in isolation.
Our company started off with a TFS project for each "real" project, but we constantly ran up against problems due to this until we reorganised our entire codebase into one collection containing 3 projects, for Documents, Assets, and Code (three distinct areas with no interdependencies)
Within a project you can still organise the code into folders so IMO there really isn't much point in using different projects and collections unless you have very different access/security requirements for the different codebases (which is unlikely if they have no dependencies).
The other approach is to use the 3 collections you describe, but eliminate the "live" dependencies between them by pre-building the libraries in DefaultCollection to provide a shared repository of binaries that you can link to from the code in the other collections. This could also help with versioning, where the library code could be updated but the binary not merged into one of your other collections immediately, allowing the teams that work on the other collections to pull in updates to the library code only when it suits them. This can help stop problems being caused by changes for team A being immediately used by team B.
We have a project that will be developed in multiple phases over the next 12- 18 months. It's an agile-esque project in a waterfall environment, it that matters.
My initial thought was to create one team project named 'Project X'. Under Project X could be multiple solution folders but the main development would be in a folder called Main. Branching would be done as appropriate.
The other solution folders under the Project X team project would be for some of the tools we need to build for this project that are independ of the main app, which is a web app. For example, we needed to build an app for processing data and sending it to a web service but it never interacted or merged in any way with the main web app.
The advantages I see to this approach are a) all the code for the project is kept under a single team project and b) all the work items, bugs, wishlist items, are accessible from all the other projects.
Does this approach make sense? Any ideas to improve this? I haven't created the team project yet.
I will simply comment on the advantages you listed to help you understand why this approach isn't ideal.
The advantages I see to this approach
are a) all the code for the project is
kept under a single team project and
Both your tools and your web application are for "This project." That right there is a key indicator that you should use one Team Project inside of TFS. You gain nothing by having two separate Team Projects. In fact, you may make it more difficult to manage.
Consider if you have a requirement that has work one both a tool and the main application to complete. In your scenario, there would be no way to track work history associated to one requirement because you are using two Team Projects. There are many more reasons, you have to manage permissions in two places, have two sets of mappings etc etc.
I would highly recommend you opt to use one Team Project. You, and your entire team, will thank me later.
b) all the work items, bugs, wishlist
items, are accessible from all the
other projects
If you have two Team Projects, you cannot access WIs etc across the projects. In fact, you will have the exact opposite- you will have to create the WIs in both projects if the work crossed over between the two.
You should have one Team Project. A folder for the tools and a folder for the web application. From there you can take it further having it branched off- a branch for development and a branch for main is a good start. Inside each, have the tools and web application so the versions stay in sync.
Here is a good place to start reading before setting up your project: Microsoft Team Foundation Server Branching Guidance.
What you're describing is not a Team Project. You're simply describing the structure of some source control folders in TFS.
A Team Project is a lot more than just source control. From T (Visual Studio ALM Glossary):
team project
The named collection of work items,
code, tests, work products, metrics,
and so forth, used by a defined team
with Visual Studio Team Foundation to
track a common set of related work.
This is a follow-up question to my original query:
How can I use multiple projects to separate a large ASP.NET MVC site into departments?
Now that I have this working, is there a way to still have multiple project but not have to reference each child area from the parent project? Ideally I'd like to be able to have multiple, separate and distinct projects that only come together on the production/test machines. I should be able to build and test each "area" separately.
Not in MVC 2 Beta. Perhaps a future release.