I am at the point in azure manager where I have to choose for xamarin.forms: create new app(too much unnecessary content) or connect an existing app(which I think is better). I have a blank xamarin.forms project and I cannot figure out in which specific files to put necessary items, basically I would like to know the file names and place to put each item in according to this(starting from "In your main Activity file...").For example, which is the main Activity file?
If you want to create Xamarin.form app with Azure, you can take a look the following article:
https://learn.microsoft.com/en-us/azure/app-service-mobile/app-service-mobile-xamarin-forms-get-started
And you could be confused about xamarin.form folder, when you click corss-platform---Mobile App---OK, your solution will be created with four projects, you will have three platform-specific projects and one Shared Project. The Shared Project contains the application logic as well as all the Xamarin.Forms code that will be in charge of creating the screens (Page objects) of your application. More detailed info, you can take a look the following article---Creating basic Application.
https://code.tutsplus.com/tutorials/getting-started-with-xamarinforms-basics--cms-21564
Related
https://azure.microsoft.com/en-us/updates/new-azure-api-management-developer-portal-is-now-generally-available/
Extensibility—The portal comes built into every API Management instance (excluding the Consumption tier). If you wish to extend the portal’s core functionality (for example, create your own widgets to fetch data from other sources), fork the GitHub repository, implement the code changes, and self-host your own modified version of the portal.
Is it so that we can't do custom widgets on Azure hosted Developer portal? If so, then this is a backstep from the legacy portal as there we could write custom HTML and JS to get custom features.
I believe still there are couple of things you can do.
Home page
The default Home page is filled with dummy content. You can either remove the whole sections with the content or keep the structure and adjust the elements one by one. Replace the generated text and images with your own and make sure the links point to desired locations.
Layouts
Replace the automatically generated logo in the navigation bar with your own image.
Edit the content of the portal, customize the website's look, and publish the changes.
Please refer https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-developer-portal-customize and let me know how it goes
You can submit a pull request to the repository.
If you create a custom widget and this will be useful for many users it can be included in the default set of widgets.
I have a WebAPI running on Azure WebApps developed with EF Code First.
Now I need WebJobs for some scheduling tasks which should refer to the same DB and Models.
I tried adding reference of the WebAPI project but that marks the DLL as yellow exclamation.
I'm unable to get how should I proceed. Can you please guide me a bit?
As Frederico suggests, you should split your Web API project into multiple projects.
If you isolate the Data Access Layer (EF Context + query) into a separated assembly, it will be easier for you to share the database access into several projects. Moreover you will not have to add reference to web specific dll (for example System.Web.Mvc or System.Web.Razor) into your webjob project.
Anyway you have some yellow warning because your Web API and you Azure web job don't target the same .Net framework.
Right-click on your project then select properties. you should be able to adjust the .Net Target framework.
To be able to reference a project A into project B, the project A should target a .Net framework with a version less or equals than the targeting .Net framework of the project B
I assume that your EF DbContext class and entities resides inside your Web API project. This monolithic approach brings many problems in integration scenarios like the one you shown.
My advice is to modularize your solution and move all your Data Access related classes (DbContext, entities) inside another project which will be referenced by both your Web API and WebJobs projects.
This is a common approach for improving the maintainability of the code and enforce basic software engineering principles like separation of concerns, and is obtained by dividing your application into different functional layers (a.k.a. multi-layered architecture).
If you are interested you can read more about it here: https://msdn.microsoft.com/en-us/library/ee658109.aspx?f=255&MSPPError=-2147217396
Why do we need a list definition to create custom list in visual studio?
I can create a custom list using the UI without the need for visual studio.
So what is the advantage of using a list definition to create a custom list in visual studio?
The UI can only create a list on a single server, in a single site. You can't copy this list to a different server, eg. to deploy it from your development machine to the production server.
It's also difficult to use the same list in different site collections or web applications. While you can save a list as a template, you can only use this template in the site collection it was created in.
The only way to define a list that you can easily deploy to multiple servers is by creating a list definition. Otherwise you'll have to backup and restore your entire site from one server to the other, or use third party tools that will do essentially the same thing.
Deploying using a list definition can take seconds. Deploying by backup/restore can actually take days, as SP will only warn you that something went wrong only AFTER the entire restore process has finished.
Furthermore, there are form customizations that can't be done without modifying the actual list definition, eg. hiding columns. If you create the list through the UI you'll have to use a third party tool to make the modifications.
Would also add, when doing development, you will need a procedure to migrate your code from DEV ennvironment to Your UAT environmet and then onto Production envirnment
If you do this manually it will take some time, also there is always a risk you have not created it the same way.
using list definations will make sure it is the same on each environment
I am making several web applications. What I want to do here is:
Applications should stand alone in IIS using differnt application pool.
There is one main application used solo as front page, allowing log in/out and navigate users to other applications.
I want other applications to use the layout of the main application.
The structure I was thinking was to deploy the main application under root folder of the website and host other applications under it in seperate folder (seperate application and pool). Something like:
IIS
|
|__Main app (web site)
|
|__App1
|
|__App2
However, I just got confused here:
How can I reuse the layout/dll acorss apps/pools without copying them into each application (Maybe it's a silly question)
How can I use MVC3 controller/action feature instead of directly using hard coded <a/> to navigate users to each application. I actually tried it. Looks like the Main app (MVC3) can only recognize controller and view in it's own project.
In summary, what I try to do is: Deploying my applications in the tree sturcture above and let the main app bring views from sub apps and display in main app's frame.
Maybe it's not a good practise, but any suggetion is welcomed!!!
Thanks a lot
It really sounds like you would want to make use of Areas in MVC. This wouldn't allow you to run the nested "applications" in their own App Pool, but it would accomplish everything else you are looking to do (shared layouts, dlls, Html.ActionLink, roles based access to each Area, etc). You can easily share top level navigation across all Areas and have different sub navigation for each. I have a 2 part blog post about using a single layout that is shared across Areas that might give you some help (or ideas).
Single Layout for Areas with ASPX and Razor views (Part 1) - Using the ASPX View Engine
Single Layout for Areas with ASPX and Razor views (Part 2) - Using the Razor View Engine
If you felt that having sub apps in Areas in a single project was too rigid you could also look into using MvcContrib to make your sub apps in Portable Areas and then consume them in your top level app.
My team is working on a project to migrate a .com site into SharePoint.
After all our look and feel assets, master pages, content types, and page layouts are created, we need to actually "move" the actual site pages into SharePoint.
I'm trying to come up with the most effective way to do this. Our topology consists of an Authoring and a Production environment. We plan to use SharePoint Content Deployment to populate Production from Authoring.
However, we obviously need to do some sort of initial population of the Authoring environment. I don't want to use Content Deployment to populate Authoring from a development environment because I don't want to initially create Authoring from a Blank Site definition.
Here are the options I came up with, would love some feedback on which you think would be the best approach:
Create the site content in a development environment and use a tool such as SPDeploy to migrate it into the Authoring environment
Create the content directly in the Authoring environment
Use a technique similar to how you can provision List Item instances in a feature. We would create and populate all of our content using Features
I'm not sure if this is actually doable, but got the idea because of how I know you can create List Item instances when provisioning a List in a feature. After all, our Pages library is a list of Pages - however there are multiple content types involved.
Thank you for your suggestions!
If it is just a matter of migrating files, you could actually use the content migration framework. The core classes of this framework are the SPExport and SPImport classes in the Microsoft.SharePoint.Deployment namespace. You can with fairly little code export individual files to disk and import them again to a new location. Alternatively, try the SharePoint Content Deployment Wizard on CodePlex here: http://www.codeplex.com/SPDeploymentWizard. It will save you the coding.
Backup and restore the content DB.
Can you clarify on why you don't want to use content deployment to create your initial Authoring site? Why do you not want to start with a blank site definition? It would get overwritten in the deployment process anyway. What about stsadm -export / -import?
I'm sorry, but I'm still not clear on the whole situation. You have a development environment (presumably where structure is created, but not any content destined for production), an authoring environment (which I understand as a locked down environment where content is entered and approved), and then a read-only production environment to which approved items are deployed. If this is the case, then I can say that I have a similar setup on one of my projects.
In my case, I initially developed the site structure in my dev environment, then backed up and restored to authoring and prod. Subsequent structural changes to both environments are made by hand. Authoring is structurally almost exactly the same as prod. Only the security is different. Several times per day content is deployed from authoring to prod. We make content changes directly in the authoring environment.