Scenario : A web application with user login, roles and permissions.
Question :
Is it better to start with Visual Studio's / Visual Web developer Express edition's project wizard which contains the user management with it OR start an empty project?
If started with wizard, How can I move the membership and role Database tables to my own database?
Programatically working with Membership and roles. How?
If started with empty project, How can I manage membership and roles etc. ?
How to add new fields in user profile?
I am in student level in .NET. Above are some confusions I encountered while trying to start developing a project. It might be some silly question. Please do not ignore. Guide me with some helpful hints and good links if necessary.
EDIT:
I found a good tutorial here : http://www.codeproject.com/KB/aspnet/ASPDOTNETauthentication.aspx
It solved 50% of my problem.
It sounds like you need to start with some good tutorials on how to do authentication. Here are a couple that I think would be helpful:
http://www.csharpfriends.com/Articles/getArticle.aspx?articleID=70
http://www.youtube.com/watch?v=8t1MoIsMUKE
Because you have a student level understanding of .NET, I would recommend practicing a few times using these and other tutorials before trying to do everything you want to do.
As for wizard vs. empty project, I don't like wizards. There is too much I want to change and if I forget about something I end up with code bits hanging around and that is never good.
If you code the system by hand and store your authentication information in a database, you can manage the roles/permissions/etc. with simple SQL calls.
Related
Attempting to migrate a web part solution from farm solution to sandbox solution. The steps I have seen online outline changing a property at the project level which is a boolean called 'Sandbox Solution'. However I do not see this option when I view the properties of the project. Does anyone have and ideas on how to migrate a solution which contains multiple web parts from a farm solution to sandbox?
I am afraid this can't be done. When a farm solution is created and deployed it loads extra controls into the solution that allows the solution to easily access data outside of its container. An example is the user control. This control is not allowed in a Sandbox solution as it allows access to the SharePoint root. Just changing that option isn't going to revert that option because the entire solution is geared around it even if you don't use it. It will be deployed. I found the blog post you are talking about or one similar to it and have never seen that work. This is why you define your project type at the beginning because Visual Studio applies the different controls depending on your selection. Removing the sandbox and recompiling will not work.
On another note, you can however convert a sandbox solution to a farm solution. This is because you are moving from stronger security to "less"
I am working on a new project and instead of creating a single project with the UI and Web Services in the same project I want to separate them into two projects. Like the image.
What project types in Visual Studio 2013 would you use to do this. I know that I can do everything by hand but...
I have tried the WebAPI project type but it assumes everything in 1 project.
I know someone else has wrestled this issue so I would appreciate your input.
Any advice would be appreciated.
I think you might be confusing "projects" with "solutions". It sounds like you should just start with a Blank Solution and develop out the different projects. There's no reason why all of these couldn't live within the same solution.
I think that Mr. Beam missed the point of the question in that Mr. Washington is asking about the project types to create shared services that are called by and UI type project.
I think just creating an empty project with the WebAPI inclusion would be what you want. You could then to REST calls to your service layer project with no other overhead.
JD
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 have an internal installation of Agilefant. We are done with the first sprint and already started the second one now our client asked access to Agilefant so he can check our progress. The problem is that we have multiple projects inside of our installation and we don't want them to see the other projects:) You can understand that:)
If I'm right you cannot restrict an Agilefant user to have access only for one product, he will see all of them (please correct if I'm wrong).
So the solution is to make another installation and somehow migrate the project to that installation. Is there an easy way to do this?
I'm open for other solutions.
I've got a great answer for my question from jarno a site administrator on the Agilefant Community Forum. There are no easy ways to achieve a product's migration yet. Although jarno described two ways how you can do it:
a) You can take a copy of your database, put it into another Agilefant instance and delete all products that you don't need. Then you can create users for your client.
b) You can adopt Agilefant 3.0 alpha X. You will be able to restrict product access based on teams with Agilefant 3.0 alpha X!
You can find more details and known issues with this version of Agilefant on the link below:
http://agilefant.freeforums.org/how-can-i-migrate-a-product-from-an-agilefant-installation-t205.html
My enterprise is about to start a somewhat complex project in which we will probably use Domain Driven Design for the business layer. The project will be developed using Visual Studio 2010, and managed via TFS 2010 using the CMMI 5.0 team project template.
I think that it would be a good idea to use TFS work items to track and manage the definition of the domain entities and the value objects in the business layer. However is seems that the CMMI project template does not have any suitable work item for this. I have tought of the following workarounds:
Use the Requirements work item,
modifying it so that the
Requirement type field has one more possible value, such as "Domain
Entity".
Add a new work item to the project
template.
Give up and do not use TFS to manage domain entities, tracking them on a separate document instead.
My questions are: What would be in your opinion the most appropriate approach? And, has anyone done something similar (managing domain entities using TFS work items) in the past?
Note: I've not heard of anyone trying this before, so YMMV :-)
I'd be inclined to add a new work item type, and link requirements to the domain entities so that you can see which requirements impact which entities, and you can also link domain entities to other entities.
I'd also be inclined to include other informaiton on the work item such as context, aggregate root, etc so that the entity work item has a little more information around it.
Doing it with TFS work items gives you history and tracking, which may well make it may be worth doing, however I'd also ensure I have links from the entity work items to the domain doco as well, assuming it's stored in something like the project portal or other repository.