When I am creating a custom module containing my own Controllers and Views, the default project created by Code Generation creates a project that is like MVC but Visual Studio does not recognize it as an MVC project so it doesn't offer the normal "Add View" tooling as it does in a "real" MVC project.
I have seen posts talking about changing the Project type GUID in the project file but I am hoping there is an alternative to this approach. I have also seen tutorials where the presenter is using Resharper. I am currently not a Resharper user so I am not ready to adopt this approach either.
Are there project templates available? Any Code Generation module features I can take advantage of? I mainly want to find out how people are doing this now to make the development workflow go faster.
Thanks,
Brian
Yes, that's what the code generation tool does, so that we can reduce the Orchard requirements just to ASP.NET 4. Now a module is just a project and a manifest, living in a subfolder of Modules. There is nothing magical about the command-line and it's perfectly fine to create the project from VS. Or you can modify the code generation command so it adds the project type guid at creation. Both choices are valid, you just need to be aware that if there are other users than yourself, you might prevent them from opening the module in VS unless they install the MVC tooling first. That should not be a big problem, but just something to be aware of.
Related
VS2013 update 5, MVC5 using Areas
I have a stand-alone function programmed for a website. The functionality is a specific user interface to collect survey responses in a particular way. It has several controllers, a model and a group of views. The functionality is completely contained in an Area of the project, except for the Shared _Layout file that provides the main menu for consistency.
'Is it possible for me to' / 'how do I' compile this Area into a single or set of .dll file(s) that I could then add conveniently to other websites? I'm assuming creating something for transfer/download is very standard functionality. For example, I used Elmah.MVC for this site. What I want to do is pretty much create a package that can be downloaded in a similar way to how we integrate Elmah.MVC into a site. (Be certain I'm not talking about creating error logging software, I'm only using Elmah.MVC as an example of software that is easily integrated into other website applications.)
I've never compiled any website functionality into a .dll(s) for use elsewhere and would appreciate either some specific guidance, or perhaps what would be easier is to provide a link with a good step by step tutorial or explanation for how to do this. Most of what I've found on the web describes bits and pieces of doing this, but it's not enough for me to feel confident with it.
It seems to me there are a lot of 'moving parts' to taking a particular piece of an MVC application and turning it into something that is easily added to other projects.
A particular issue I don't quite grasp is the difference in downloaded packages between getting code and getting just the .dll(s). For instance, when I download an MVC5 site, I get controllers, models and views, but when I download Elmah I get a .dll and no code files. Also, I do understand the concept of transforms, but I'm just struggling right now with even getting from my programmed application into a 'package' regardless of the transforms that make it easy to integrate into another website.
These are just some of my questions I have about how to perform this particular process in developing deliverable and/or shareable software.
What you are looking to do is create a portable MVC Area project. A Portable Area is a set of reusable multi page functionality can be dropped into an application to provide rich functionality without having to custom build functionality that is literally the same in every application. An MVC Portable Area is really just a dll that contains the views, controllers, scripts, etc… needed to use in a website that is either a Web Forms website or an MVC website. A developer can use them for a reusable widget or a complete engine. I have actually used them for both. Here is a link with some basic info to get started. http://elegantcode.com/2012/04/06/mvc-portable-areas/
The project I’m working on is revamping an existing web portal.
Migration from the old controls (Infragistics) to a new suite (Telerik) is part of the revamp.
Would you recommend to keep the old Visual studio project and put the new controls in or starting a new VS project altogether?
It depends on how much you are using the third party controls and what portion of your site it is. If it is a small portion it may be better to continue with the existing project. If you have very heavy usage of the third party controls that you are removing on each page a rewrite may be easier.
If you are looking at possibly rewriting using a new project you may also want to consider the technology that you are using as well. For example if you were using ASP.NET Web Forms before, maybe it would make sense to use ASP.NET MVC now.
I believe the best answer to your question is that you need to evaluate what you are using and the amount of work that each approach will require and determine what is best for your specific scenario.
I have an existing ASP.NET MVC 4 project that already uses ServiceStack for REST services, and I just read all about ServiceStack.Razor and would love to move the entire project onto ServiceStack. Right now there is only one controller and view besides the built-in AccountController, and that controller just returns the view and the view is really just HTML; everything else is HTML/CSS/JS + ServiceStack REST.
The only real legacy constraint here is that this new app still needs to make use of SimpleMembership. At present I'm using a custom auth provider to authenticate against SimpleMembership and I would like to be able to continue to do so.
So, what would be the best recommended path to achieve this end? Can I get what I want by modifying my existing project by removing some references, or should I start fresh with an empty ASP.NET app and move the old stuff into it? Can I have SimpleMembership without introducing dependencies that will step all over ServiceStack.Razor?
If you were to start a new solution using only servicestack then MVC would never be there to get in the way.
I use servicestack.razor and love it. It is a lot simpler than MVC in my opinion. Moving everything to the new solution is pretty much going to be copy and paste since what you have works. I wouldn't hesitate and would make the move sooner than later. In the end you are not gaining anything from MVC. You only gain using servicestack. A big deal for me is self-hosting and eventually moving to mono.
This is a question that will have answers based off opinion so I suspect you will receive a few. I have not personally performed such a migration so this is only opinion but is how I would approach it. However, my recommended approach would be:
Retain the existing application/ Given its current simplicity, creating a new app and moving existing items into it seems unnecessary.
You should be able to use your existing auth solution via SimpleMembership and use ServiceStack.Razor. I would proceed as such however it does depend on what other ServiceStack features you may use which could cause conflict. A ServiceStack expert could comment more on this. Even if that did occur, you would be able to work around it relatively easy. At worst, implementing a simple handler would get around almost all issues from an authentication perspective.
Working with different razor engines is relatively easy to do and you can use/enable/disable existing or new build engines via a few lines of code. See here for an example. This should alleviate any concerns around dependencies of other built in or custom engines.
Consider looking at ASp.Net 4.5.1/VS 2013 (since your project is in early days) as it has enhanced membership support and is moving to a more "less dependent" model of components via the Owin stack Asp.Net 4.5.1 and VS 2013. Katana is a microsoft project that also provides some Owin based authentication components see here and here which you could use now and this would remove a lot of dependencies and enable you to migrate other framework with relative ease. Downside is that Katana/Owin has a little ramp up time/learning curve. Again, given your project is in its formative days I would recommend looking into Katana and the ASP.Net vNext stuff as this will make it easier for you and means you dont have to migrate to the new version once it is released.
What is your approach for creating your own set of controls aka own Extensions Library? After a few years of Xpages development we have a huge set of controls that are general purpose for building UI, some web services etc. (Probably as most other developers.) When we start a new project now we have to copy the entire stuff from one database to new one which involves controls, jars, css, images, JAVA code ... and then you completely loose control to maintain some central version of this controls & codes, everything is scattered among several projects/databases and things get messy fast.
We have thought about creating our own extension library as described here
http://www-10.lotus.com/ldd/ddwiki.nsf/dx/Master_Table_of_Contents_for_XPages_Extensibility_APIs_Developer_Guide but there is not enough documentation for this topic and the entire development process is quite complicated (at least seems to me. I tried two times based on docs above going through eclipse plugin project -> feature project -> update site and still having some bugs around)
What is your experience and approach for creating and maintaining shared Xpages controls in your Domino environment? Is there some hidden feature we miss here that can help us?
Take a look at the XSP Starter Kit on OpenNTF and the XPages SDK to setup an eclipse environment for plugin development. You'll also want Eclipse IDE for RCP and RAP Developers. Install the starter kit and SDK into eclipse and you should be all set.
The starter kit is a sample plugin with all kinds of examples of phase listeners, components, etc. Once you want to deploy your plugin, create an update site from within eclipse and use the Update Site NSF available on your server install to place your update site. Once that's done, you can replicate that NSF to any other servers that may need the plugin.
For more information about the starter kit, take a look at this slide deck. There is also a github project for the starter kit. Documentation for the XPages SDK can be found here. And a video for setting up the SDK is available on youtube. Lastly, here's the documentation for setting up the update site NSF.
While we haven't gotten to that yet in XPages, our model for regular Notes design elements is to have a central template that contains the elements that are shared, with those specific design elements marked to inherit from that template. Sometimes, a database inherits design elements from two different central templates.
That way, those centrally controlled design elements remain the same in all databases.
I would recommend looking at some example's on github for how they have library/components setup. One of the more simpler examples that has just a single component built into a Library is Steve Pridemore's App Layout Extension...https://github.com/DominoDev, Another good one is Nathan Freeman's Starterkit: https://github.com/the-ntf/xspstarterkit. Hopefully these will help you get the file structure down on which files you need and how they work.
What would be the best practice to share busines logic c# code between MonoTouch and Mono For Android projects?
Edited:
Initially, my question was about the physical file sharing:
What do you propose to use: network file sharing or some code
version control (git, svn)? In my case I am using two workstations -
Mac (MonoDevelop with MonoTouch) and PC (Visual Studio with
MonoDroid).
What about Solution/Project folder structure? In
"Blog Post: Xamarin Mobile World Congress 2012 Unofficial
Conference App Released!" example structure is quite confusing:
several solutions in one folder and then different platform projects in one
subfolder with different folder and project names. It can not be accomplished nativly
with IDE. Are they editing content of solution files and folder names manualy
outside of IDE environment?
And for projects of common code what kind of profile (template) to
use? Monotouch has several: Empty Project, MonoTouch Library
Project and MonoTouch Binding Projects? In Android i supose -
Android class library?
This is a very general question, but here are a few resources that may help you get started:
Video: Cross-platform Mobile Development
Blog Post: Shared Libraries For Windows Phone 7, MonoDroid and Beyond
Book: Mobile Development with C#
Blog Post: Xamarin Mobile World Congress 2012 Unofficial Conference App Released!
Edit (to answer your new questions)
The idea behind linking files across projects is that there is only one actual copy of the file, rather than having to manage multiple copies and keep them in sync yourself. The file will actually exist in just one project and be linked into the others, but when the projects are compiled it treats the file as if it were actually there.
I can't speak to exactly how they created their folder structure, but I know there have been many cases where I would manually edit project or solution files to get the folder structure I want, because there was no way to get what I wanted through the IDE alone. This really boils down to personal preference on how you want your folders to be structured.
In the end, what you need is a class library project for every platform you want to target. When going with the linked file approach, it's totally up to you where you put the physical files. One approach I use often is to actually create a standard .NET 4.0 class library, put the files in there, and then link them into my Mono for Android and MonoTouch class libraries. If all you care about is targeting iOS and Android, that may be more trouble than it's worth, and you can just let the files live in one project and link them into the other.
Disclaimer: I've got a particular Mvvm methodology that I use for sharing code across multi-platform projects...
Despite this, I genuinely don't believe in "one size fits all" frameworks - I think you need to be careful to pick an approach that best suits your project, your developers and your organisation.
With that said, some of the tools you can use within the Mono development approach are:
using Portable Class Libraries to share exactly the same code between platforms
using platform specific Class Libraries to share code between platforms, linking these using the Project Linker tool from Microsoft
using #define code within your class libraries to provide platform specific implementations of the projects (I personally try to avoid this approach, but it does often provide the quickest route to market)
using DI/IoC techniques to provide components for those occasions when platform specific implementations really are required.
using a assembly linking to provide IoC - e.g. this is what the Xamarin MobileAPI does
using server-based logic for genuine shared functionality - e.g. using REST or SOAP-XML services to implement logic
sharing tests (e.g. NUnit) between platforms to assure the quality of your logic
using shared code techniques - MVC (MonoCross) or MVVM (MonoMobile.Views or MvvmCross) for UI "controller" logic; MonoTouch.Dialog and MonoDroid.Dialog for "View-level" abstractions; CrossGraphics for UI "drawing"; SQLite.Net for database; etc.
I'm finding the MonoTouch, MonoDroid and the Microsoft tools provide real and signigicant benefits in developing cross platform code - but you do have to work and think to achieve this.