0

I just need help getting started in the right direction.

We are using Sharepoint 2016 On-Prem for our intranet. We haven't done anything beyond OTB features, and simple content editor web parts. But I was just assigned with moving another tool onto the Sharepoint Intranet page and I'm not sure where to start.

We have a lookup tool, that is web-based, that uses a free C# MVC product. all this tool does is allow user input into a single field and gives the users several buttons (different pages that pull/analyze data from a database) to run based on the input the user-provided. This tool was created before I got here, no one on the staff is trained on the free c# platform, and management wants to port it into the current intranet.

While I have been a 'power user' of SharePoint for years, I've never had to do anything like this before. What I was thinking of doing was just creating a single page in SharePoint. I can create a page in our site pages, but if I want to add custom code-behind and autocomplete, auto data refresh, etc..., where would I go? how would I get started? is there another way that I should be using to add this in? can I do all of that in SharePoint designer, or is there some way that I can do that in VS for the page I created?

Thanks for any help/advice you can provide!

1 Answer 1

0

The process of creating custom .aspx pages with code behind really hasn't changed much in SharePoint since 2007 -- which unfortunately means that you will not get an MVC app to run natively as a server-side SharePoint solution without completely rewriting it WebForms. However, there are definitely better ways to get your solution working that trying to re-write it as .aspx code-behind WebForms.

The easiest way, but possibly clunky depending on how the user interface of your MVC-based works, is to leave the current app where it is, and stick an Iframe via a content editor webpart using the url of your MVC Lookup tool.

The longer term and "better" way, but more work, would be to first make sure your MVC app exposes all the data and services you need through an MVC api. Depending on how long ago the app was written and how it was architected, this effort could range from nearly nothing to painful. Once the API is running, you can then design and construct a JavaScript solution built on a framework like React or Angular, to then be hosted in a page in your SharePoint environment using either the Content Editor or Script Editor webparts. While this is more work than the IFrame approach, it is still likely less work than rewriting the app as a code-behind WebForms solution, and doing it this way makes it more future-compatible with any potential moves to an Azure-O365 cloud-hosted environment.

If you truly want to create a custom .aspx pages with code behind, this article from c# corner is as good a starting place as any.

2
  • We would like to fully shut down the other MVC app, so re-writing in custom .aspx pages is probably the only option. I think your link is going to be a good start. Thanks! Commented Dec 29, 2019 at 20:07
  • I seems like you're taking a bit of a step backwards technology-wise to rewrite an MVC app in .aspx, not to mention would be completely incompatible with the cloud. What is the driver behind wanting to shut down the MVC app? If the goal is to reclaim or decommision whatever server hardware is hosting your MVC app, you could always configure a new IIS site on the same machine as your SharePoint Web Front End, and simply host them together even though the app would still be a separate tool.
    – willman
    Commented Dec 29, 2019 at 20:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.