I'm using Visual studio 2015 to develop multiple angular2 single page apps. The applications share some common components (Login, header, footer etc) and also I like to have only single node_modules accessible to all the apps. The apps are in single VS project within their own directories current setup that I have:
As per the best practices what is best structure for the VS solution/project?
Maybe you should consider creating ONE app but with MULTIPLE ng2 modules like DealFinderModule, JobBoardModule, SharedModule. Using modular system is considered to be the best practice and will help you achieve your goals
Related
I recently deleted JQueryMobile.js from my project and am now trying to apply the classes so I that I can link the css. In order to do this I need a side by side comparison of the two projects(the other one having JQuery Mobile still). I copied the old project to a separate folder. I then opened them up in different instances of Visual Studio 2012. Problem is that only the one with JQuery Mobile ever works, and the programs use the same port. How can I fix this so that I can run the two different versions of the same project at the same time?
Why don't just give the projects different ports? Go to Properties of your project, Web tab and in Servers pick IIS Express making sure that both have different ports.
I have an Visual Studio 2010 empty sharepoint solution project. Solutions consist of several custom lists and workflows attached to that lists. The solution always changes, so it means I'm redeploying the solution very often. After deploying it deletes all of the content from the existed lists and recreates that lists again. Now I'm considering the ways how to solve the problem of disappearing of the data, are there effective ways?
p.s. I cannot use lists created in UI, because I need custom defined lists.
You cannot prevent visual studio from deleting and creating lists, it is by design to ease development.
During my SharePoint development I've found some workarounds:
1) Put all list instance artifacts in separate project and do not redeploy this project. You can have other project with web parts, workflows etc which you can redeploy.
2) If you change only code and not any SharePoint artifacts then you can use some useful features of wspbuilder exteinsions - it adds custom "WSP builder" option to "Tools" menu. It allows you to deploy your assemblies to GAC without redeploying wsp packages and restart IIS and Timer Service.
I am developing a SAAS application using MVC 3 and Windows Azure. I am developing in Visual Studio 2010.
As I will have a main website which promotes the product, what I want to be able to do is have my website and application separate. Would this be feasible to do it in the same solution and add as a separate project?
sure in Visual Studio 2010 you can have different projects in the same solution.
You can for example create a class library project for the Business Logic, another one for the Entities, a common one for the interfaces and another one for the data layer (with or without Entity Framework models...).
In the same solution you can then add a web application project which uses MVC 3 and C#.
In general for big projects you would have multiple solutions with many projects inside any of them. It depends really on the size of your whole architecture.
To decouple things nicely, you should imagine to communicate from MVC site to the business logic not via direct project reference but for example via web servives (XML or better WCF), so your business logic can be installed aferwards also on another machine than the web servers (for example an application server) and the web ui will just use a different machine name or ip address to direct all the WCF calls. we use this approach successfully in several projects.
Visual Studio allows you to make "Web Sites" and "Web Applications", but, inside a project, can you have one within the other?
Say I have my website "www.mysite.com" and I have an application called "BudgetCalculator". One the production server, this is supposed to be located at:
www.mysite.com/BudgetCalculator
And the BudgetCalculator app contains links back to other parts of the website, like "/page1" and "/page2".
However in Visual Studio, when they're listed as two different projects, they're on the same level. When I fire up the debugger for the BudgetCalculator app, those links aren't going to point back to the main website, like they should.
Is there a way around this?
One solution would be to stop using the built-in .NET Web Server.
Use IIS, create one site, and make your Web App a Virtual Directory inside of the Web Site.
A project cannot host/contain another project in Visual Studio.
You can however create a project that sites in the directory of another higher level project when you create it, however they may not be directly linked, so you couldn't debug them both at the same time.
My SharePoint Visual Studio solution structure currently contains these projects:
Common: contains extension methods, helpers, frequently used controls, etc.
Logging: would normally be included in Common but contains calls to native methods so marked 'unsafe'
Site-specific project: one for each distinct site, containing features, web parts, event receivers, etc. specific to that site
Console app: console app projects as/if needed
I'm using WSPBuilder hence each project (apart from the console apps) has its own SharePoint WSP solution file.
Is this a good way to split up SharePoint code? What approaches do you use?
That seems reasonable, though you might want to be careful about the deployment of the shared projects - The deployment script probably includes updating the common package, which isn't good for older site specific projects.
For most projects I prefer to have a single solution package with necessary shared libraries included - usually being installed to the GAC.
If you aren't doing this already, I would consider bundling your common code into one or more features and have the non-common code be in a feature with a feature dependency to the common code. You may want to have the common code use a different WSP or the same WSP - not sure of all of the pros/cons of that.