I'm building a SP provider hosted app in Visual Studio. I just saw, that for each list I add to the project a new "Feature" is added, too. Can someone explain what the tasks of a feature are and how it is associated with the lists? Thank you!
You can see the feature as a container with yours SharePoint artefacts.
Basically, if you need to define a list, you'll have to create a definition list.
Then, you have to put this definition in a feature.
When your app'll be launched. The feature will be activated and the list inside your feature will be deployed on your site.
The features managment depends according to the developper. You can :
Put all in one feature. Sounds ok for small apps with one list.
Have one feature for the fields, on for the content type and one for the definition lists
Have one feature by fields/CT/list.
To separate lists will provide you more intel in case of error. You'll know that your specific feature in error manage a specific list. And you'll directly analyse what's wrong in your list. (Useful when the error is "An error has occured during the activation on the feature xxxx-xxxx-xxxx ... The log aren't everytime explicit)
In another hand, some developper'll tell that manage multiple features is an additional work. Up to you to weighing it up !
Note : In a SharePoint-hosted app, all the features are scoped web.
Related
It's unclear how the repositories are connected and tied together. Each git repo has a different package of cs files, with their own unique features and design schemas. Rather than a hierarchical design structure, where in my understanding or example:
Abp-base (free git repo), would have core essentials
AbpZero-paid (membership subscription to premium git repo), would add additional features into their design that would encourage others to pay for.
AbpZeroTemplate-demo (download from website, not git), would be a sample utilizing the paid content to push and drive sales to unlock the tool to it's full potential.
I downloaded and even paid for the different tiers, but all of the contents are all over the place. When I tried to combine them so that I could take advantage of a complete product, nothing lined up properly, and I get breakage everywhere.
How am I supposed to change the crucial schema design flaws when half of the .proj links to .dll that expect the class to be structured a certain way?
Example:
User is structured: "Name", "Surname". But i want it to be "Firstname", "Lastname." Some may ask, what's the difference? Just like how "Maiden name" is different from "Last name" or "Family name." Those little nuances are'nt procedural thinking. If you went to a stranger and asked "what's your name?" and they said "Chuck Jones," you would then ask to clarify, "What's your first name?"
Each git repository is running off of a different versioning number, that doesn't match with their counterpart. AbpZero is on a stable release version 5.x, and you go to GitHub for Abp and it's saying version 3.x is stable and green. And one of them is using User<TTenant,TUser> as a class, and the other is using User<TUser>. So not only am I getting mixed signals on how they're supposed to work (because git repos point to each other, and rely on .dll for continuity) but they're also not even sharing the same coding structure.
Can anybody help me merge the old and new together, or tell me the direction on how the design is being built?
Disclaimer: I'm a contributor to ASP.NET Boilerplate
ASP.NET Core is a web framework developed by Microsoft, as you know. There are plenty different applications based on it.
ABP is an application framework on top of ASP.NET Core (and MVC 5.x but it's a different story - I skip). It tries to help real life applications on top of ASP.NET Core. It has many features like advanced authorization, background jobs, javascript proxies, DDD infrastructure and so on.. This is completely free and developed on Github: https://github.com/aspnetboilerplate/aspnetboilerplate Thousands of developers are actively using it to build their applications.
ABP framework does not provide a User Interface itself, but provides the infrastructure. So, you should create an empty ASP.NET Core application, add nuget packages, configure the framework and modules, create a UI layout and some basic pages to start your development. This is also a time consuming work. That's why we have created "STARTUP TEMPLATES". There are two startup template:
(A) A free & open source startup template can be downloaded here: https://aspnetboilerplate.com/Templates (It just gets the code from https://github.com/aspnetboilerplate/module-zero-core-template and renames solution for you). This is a simple startup template (but more powerful then ASP.NET Core's standard template when you make File > New Project).
(B) A PAID startup template, which becomes the product on https://aspnetzero.com/. This template has much much more features on top of the framework. You can see all on its web site. Since it's a paid product, the Github repository is private and only available to paid customers.
You either start with template (A) or template (B). You CAN NOT combine them. I believe it's very obvious. For instance. Microsoft provides different startup templates for ASP.NET Core: One of them is Angular, one of them is Razor Pages, one of them is empty... and so on.. So, you select one of them based on your needs.
Both of (A) and (B) templates work on the ABP framework and adds via nuget packages (it's already combined/integrated).
So, after this explanation, I believe no one would even think how to combine them.
How am i supposed to change the crucial schema design flaws when half of the .proj links to .dll that expect the class to be structured a certain way?
When you use a framework or a pre-build solution, you have significant advantages. However, there is nothing in the World that has only advantages. Every solution/framework/library will come with its own limitations, you like or not.
With that in mind.. Despite of other vendors, we provide the FULL SOURCE CODE! User class or another schema class is not inside a CLOSED/SECRET DLL. They are on nuget packages and are open source as I described before. They are framework code. If you want to change the framework code it's always possible. Just download the ABP framework on Github repository, include into your solution, remove nuget packages and add project references. Then you can freely change the User class. Source code is open & here:
https://github.com/aspnetboilerplate/aspnetboilerplate/blob/dev/src/Abp.ZeroCore/Authorization/Users/AbpUser.cs
https://github.com/aspnetboilerplate/aspnetboilerplate/blob/dev/src/Abp.Zero.Common/Authorization/Users/AbpUserBase.cs
Each git repository is running off of a different versioning number
Why we follow the same version numbers for different products those are released and developed separately? Does Microsoft have same version number for all products?
I wish i had enough money as the next guy to afford throwing around $1600 a year just to resolve issues with poorly documented code, but sadly i do not
There are thousands of customers paid it and they are happy about our product and they are renewing their licenses to be able to access to latest source code after 1 year. If anybody wants a refund, we always provide a money back without any question. Refund request ratio is smaller than 0.5% because developers love our framework and product.
My membership expired while i was resolving conflict issues with the code, and i immediately lost the ability to use git repo connected to that service
You can contact info#aspnetzero.com and request the latest version of the code (when the time your license expired). We always help to our customers about that. It would be better if you had contact with us.
I am using VS.net and TFS. In the past I have stored my technical documentation (explanatory documents etc) in TFS document WSS repository and linked it to my source code via the Story, Task or other work item. This has proved unsatisfactory in the long term because the documentation is not strongly linked to the code it describes.
What options do I have to link documentation to code in VS.net/TFS other than through the work item. I can think of two options immediately -
1) Add it as Content to the project or solution itself and store it in the source code control repository
2) Add it as a URL in the code header, and store it in the TFS WSS document store.
Both these seem unsatisfactory - (1) means the documentation is not available outside the SCCS, and (2) means the programmer has to hunt through code to find the documentation link (which could be anywhere in any header).
Are there any other options that are in common use ?
Phillip
I don't know if there is a single golden answer to your question. But let me share how I do it.
Personally I split my documentation in technical and business documentation.
Technical documentation only consists of four documents:
What are we building, short document that you can give to a new developer to get quickly up to speed what the project is all about.
Instructions to compile. This document describes any steps a developer needs to take on a completely new machine to compile the code and run unit tests
Instructions to deploy. All necessary information to deploy the app to a new environment
Technologies. A list of technologies used in the project with links to more information if a developer needs to learn something.
This documentation is stored in a solution folder as part of the solution in Visual Studio.
Outside stakeholders can view this documentation through the web access of TFS. They can't change it however without having Visual Studio or Team Explorer and knowing how to use those.
For all other documentation we use SharePoint. TFS allows you to link Workitems to documents in SharePoint. We try to avoid any technical documentation in here.
Another option that you might consider is to create a new Work Item type called "document" and to have a hyperlink from here to the document location. Now you can create hard links between code files and changesets as well as PBI's to originating documentation.
In addition, when documents move you only have one place to update it.
I would like to know if is there any way to list all available projects in a user cloud account?.
I want to select one project from all available and the run all other APIs based on selected project. Now I have to write manually the project name.
Thank you.
Ok, I have found, it's not possible.
Found in https://developers.google.com/compute/docs/projects
Note: There is no Google Compute Engine command to list projects; you
must use the Developers Console to list projects of which you are a
member.
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.
In visual studio, one can create "tasks" by inserting comments like this:
//TODO: Make me a sandwich before looping.
These tasks can then be viewed under the View > Task List menu. But these tasks are entirely independent from Team Foundation Server.
It would be extremely useful to be able to automatically create a new Team Foundation work item when a TODO task is added, so that the work item can be assigned, commented, attached to, linked, and associated with check-ins, etc.
Anyone know if this is possible?
My suggestion - even if it was somehow possible:
Don't do that :)
//TODO: is very lightweight, you can add/remove/modify those lines as you like with no impact besides being source controlled.
TFS work items are much more heavyweight and process oriented (only so-and-so many state changes are allowed according to a process template).
Synchronization and keeping track would be a nightmare. Therefore I think nobody I know of does it.
We use:
//TODO: for developer comments/reminders. - Internal/developer only
WorkItems for Bug/Feature/Task tracking (Inprogress/Complete/etc.) - Team/developer/tester only.
Help Desk Request for End User visibality. - All/End Users
I don't think they should be mixed as they server different purposes.
I completely agree that turning TODO items into work items is the wrong way to go.
But considering this as a tool capability exercise I think it can be achieved.
You can define a dummy build with a custom build activity in it.
Here is a series of blog posts by Ewald Hoffman teaching how to customize Team Build.
http://www.ewaldhofman.nl/post/2010/05/13/Customize-Team-Build-2010-e28093-Part-5-Increase-AssemblyVersion.aspx
Part 5 discusses how to automatically increase assembly version with each build. He does this by including a custom activity in the build which scans through code files to catch a text pattern (in this case the assembly version xml tag) and update it.
The same approach could be used to catch TODO items (for the sake of the exercise) and work items could be created through TFS API.
Again, I do not recommend doing this but this technique could be used to solve other similar problems.