I am completely a beginner.
I am developing an ASP.NET application called College Management System. So how do I complete the architecture for this so that the application can be used by different colleges?
This application is going to be used by various colleges and universities. So if I get the tips about how the project is deployed to the clients so that all can access the application.
One last question please:
Every college must have their own application, but still all details must be available with the university as well.
University can have control of these colleges.
First of all, you need a Windows server running IIS with the feature ASP.NET.
If you want your application run separately for each colleges, you need different domains (one server or many does not matter). If you want to deploy a project, you can use the build in publisher from Visual Studio (VS).
You need to install web deploy on the server and give it access (depending on the amount of servers, you might need to create multiple sites in IIS). Publish it on each server for colleges to have their own installation. Now you need to create an system administrator panel for universities to give them the ability to make their appropriate changes.
Related
I've a dedicated machine with at least 6 diferent asp.net 4.5 applications where the developer deployed compiled versions. This apps are all working fine now, but I haven't access to source code.
Now I want to deploy this apps to Azure, but not to a VM, to an Azure Web App Service. Is it posible?
Thanks in advance!!!
Quite possibly. We can't say for sure without more information.
You'll need to FTP all files from your existing root directory/directories to your new Web App. If it's a vanilla ASP.NET web app and there aren't any dependent issues (such as databases on other servers that you cannot move or poke holes through firewalls), it should work.
There are many considerations. For instance, if the applications have dependencies on specific drive letters, you won't be able to mount those drives.
This is just one example, you can take a look at the restrictions that are imposed on Web Apps: https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox
The best way to know, is to create a new site, deploy the files, and see what breaks.
There doesn't seem to be an obvious place or any documentation from Microsoft that explains where to install complex applications which write files into the app folder and are shared by different users.
We have a complex .NET web application that contains 21 individual projects and includes the following components:
A main web site which runs a SAAS system and can be locally installed at customer sites
Applications to install, configure and diagnose
Applications which are installed as windows services
Utility applications which are installed on the server and can also be installed on clients and talk to the web app through web services
On Windows 2012 and earlier, you could quite happily deploy this application into program files, and the entire app would sit in one folder. All fine.
However from Windows 2012 R2 and later, normal user accounts cannot write to program files. Our web app contains significant uploading ability, not only of occasional use files, but also a high volume of data files which are fed from customer LANs to our SAAS system. In addition there is log file writing, and session files etc are written inside the folder that hosts the IIS web itself (edit: and the webfolder itself also exists inside our program files app folder)
From what I can gather, apps now reside in program files, and common data exists somewhere inside c:\users\public, and user specific data exists inside c:\users\username. That means the app is spread around on the hard disk and not easy to backup or administer. To follow those conventions we'd need significant rewriting as a lot of the EXE's write relative to the exe path and the web backend also relies on being able to write files inside the webfolder itself.
So is there a proper place in Windows where a complex app like this can be installed that writes to its own folder structures ?
I've noticed on Windows 2012 R2 and Windows 2016, that I CAN create a folder in the root of C: drive, whereas on Windows 10 I cannot. Would a standalone folder be the right solution to this ? It would certainly be the easiest solution for us.
The windows services and IIS app pool would always run under different credentials, so they could no longer share settings if we have a per-user model for writing files.
The app will have to conform to DoD STIG standards for web and .net applications.
thanks
What are the best practices and options for expanding to a small team ?
I am the only user of Visual Studio 2012 in my small company. I am using Visual Studio Online for Source Control (as I understand it, this exposes Microsoft Visual Studio Team Foundation Server Version Version 14.0.12345.23456 as a "service" (i.e. this is the cloud...there is no on-premise TFS installed). Currently, I am using a LOCAL workspace (the default) and TFVC (not GIT).
My development server runs IIS 7.5 on Win2008 R2. I logon locally to this dev server and launch VStudio 2012 Professional as an administrator. Project source code is on the local harddrive (e.g. d:\projects\projectA, etc.). I can interactively debug my web application projects and sit on a breakpoint without "disturbing" any other user or developer.
I work remotely so I use a mobile VPN with SSL to connect via Remote Desktop to the above development server (only 2 concurrent connections are supported now).
Some specific questions:
Can another person(s) somehow "share" the above environment?
How can developer2 and dev3 work concurrently on same project(s) as me?
Can I simply add dev2 and dev3 logons to the admin group on the dev server?
Would changing the TFS setting from LOCAL workspace to SERVER workspace enable team development (i.e. prevent checkout if already checked out, etc.)
If "sharing" the above environment is possible, what would the ideal arrangement look like (e.g. each developer has own server, own Vstudio license, etc.)?
Usually, every developer in a team has their own development machine. You create a team project in Visual Studio Online, and check in your project to this team project. When you want to dev2 and dev3 to work on this project, you can add dev2 and dev3 in the team project (Visual Studio Online provides 5 free licenses), so they can access this team project and get the project to their development machine.
Team Foundation Version Control is a centralized version control system. Typically, team members have only one version of each file on their dev machines. Historical data is maintained only on the server. Every time your team checks in their work into Visual Studio Online, you can easily audit changes and identify which user checked in a changeset.
Regarding Workspace, please check the definitions below:
•Server workspaces: Before making changes, team members publicly check
out files. Most operations require developers to be connected to the
server. (In the past teams blocked more than one person from checking
out, but this is now less common.) This system facilitates locking
work flows.
•Local workspaces: Each team member takes a copy of the
latest version of the codebase with them and works offline as needed.
Developers check in their changes and resolve conflicts as necessary.
Usually, local workspace is recommended.
More information of TFVC, you can refer to https://msdn.microsoft.com/en-us/library/ms181237%28v=vs.140%29.aspx
We have multiple clients and we use Azure web sites to host our web application. When we upgrade a client to a newer version of our software we have to upgrade all of our clients to the latest version.
We would like to be able to upgrade a subset of clients when we release a new version. This would give us the ability to test that the new solution is working properly before we bring all of our clients to the new version. We would like to offer a beta version option to selected clients so that they can access new features of our software and are aware that the version they are using is still in a 'beta' mode.
When we deploy a new version we would like to create a web site just for this new version whilst leaving the other clients on the more stable previous version. To do this we are thinking of writing a reverse proxy that directs traffic to the different versioned web sites depending on the client.
Can we host multiple versions of the web site using the same Azure web site. (IIS directories) The documentation I have read relating to this does not mention being able to build multiple versions of the web site based on different code bases.
Is there a way to set up the build so that each new version is deployed to a directory on the Azure same web site so we can effectively host multiple versions of our app under the same azure web site?
We could do every versioned build to a new Azure web site but this could get quite expensive as we run two instances so as to maintain a good SLA. It is feasible that we could end up with ten versions in the wild at once, running 20 Azure web sites to support these versions could get expensive. How can we save on costs and give our clients a good experience?
You can have up to 5 deployment slots including production on azure web apps. Each slot can use a different branch of your source control system like git or tfs. If you use any of these two, deploy is also automatic (continuous deployment) and you can swap slots any time very fast with minimium to none downtime. Each slot has it's own url for external access.
To save costs, you can run multiple web apps on the same hosting plan. There's no limit for the number of web apps running on the same hosting plan. For each hosting plan it's possible to have 10 small/medium/large instances.
Set up staging environments for web apps in Azure App Service
https://azure.microsoft.com/en-us/documentation/articles/web-sites-staged-publishing/
Azure App Service plans in-depth overview
https://azure.microsoft.com/en-us/documentation/articles/azure-web-sites-web-hosting-plans-in-depth-overview/
Yes this is possible. In management portal, You need to configure the details for the IIS virtual directory or application in the website’s configuration.
Ref - http://blogs.msdn.com/b/tomholl/archive/2014/09/22/deploying-multiple-virtual-directories-to-a-single-azure-website.aspx
Currently we deploy compiled ASP.Net applications by publishing the web site locally and emailing a zip file to the system administrator with a (usually) lengthy set of instructions for deployment. This is because the first time we deployed an ASP.Net application to a customer the dev and test IIS instance were the same, and we were unable to deploy the site twice to the same machine. This set the tone for deployment on all subsequent projects.
I am now evaluating our deployment methods and am looking specifically at the built in deployment tools; specifically I'm looking at custom installation tasks and using as much of the standard installer functionality as I can (mostly the user interface).
Secondly, I'm looking at merging deployments and automatic updates.
How do you go about deploying sofware in your organisation? What tools do you use, and what problems do you come across most frequently?
We have dedicated DEV, TEST, STAGE, and PRODUCTION servers.
We also have a dedicated build machine which runs Cruise Control.
Cruise Control is configured for a Continuous Integration build, which runs after code is checked in. It is also configured for separate Development, QA, Stage, and Production tasks.
To deploy to development, the code is first retrieved from SVN and built, then the "Precompiled Web" folder is copied to the development web site, and the web service project is copied to the development application server. Cruise Control is also configured to "tag" the source code before the build starts so we can reproduce the build at a later time, or branch from the tag if we need to do a hot fix.
To deploy to QA, the files are copied from the development machines to the QA machines.
Likewise, to deploy to Stage the files are copied from the QA machines to the Stage machines.
Finally, to deploy to production, the files are again copied from the Stage machines to the Production machines.
To configure each environment, we have a custom tool which is part of each environment's Cruise Control task that modifies connection strings, "debug=true|false", "customErrors=Off|RemoteOnly", and other environment-specific settings.
So each environment can be deployed with a button push from the Cruise Control dashboard.
One caveat is that we currently have the production database password configured in the Cruise Control config file...it would be nice move it elsewhere!
Lastly, let me add that even though our production machines are in a dedicated hosting facility, the servers are accessible from our Cruise Control machine, which makes it very easy to do a production deployment. The only manual step is to encrypt the web.config files and remove the "AppOffline.html" file that Cruise Control puts up.
Let me know if this helps, or if you have any questions.
Thanks!
A couple things that I have done is the following:
1) Use a Web Deployment Project in order to compile and clean the build as well as handing web.config section replacement if the config changes between environments.
2) Use NAnt to do all of the building, archiving, and copying in a repetitive manner.
The Web Deployment Project ends up creating a MSBuild file which can be used in place of NAnt; however, I came from a Java background and used Ant all of the time so NAnt is my preference in .Net. If you add in the NAnt Contrib tasks, you will be able to deploy not only the files but also handle items such as your source control (incase it is not part of the default tasks) and Sql Script Execution for changes.
Currently I use both of the options together. I have my NAnt build file call the Web Deployment Project through MSBuild. With the configuration manager setup for each environment, it allows me to manage the web.config section replacements automatically and still have fairly decent control over my copying and archiving of a release.
Hope this helps.
We use web deployment projects, and the VS 2008 projects to create an .msi from the output of the webdeployment & other projects. A normal windows app called 'setup' is used to do a lot of the db creation and preliminary stuff, rather than trying to customise the setup projects with custom steps. It is a lot easier to do this yourself than trying to customise the MS code. This windows app then calls the correct .msi files that the user needs.
Team foundation build runs every evening to rebuild the solution and copy everything to a 'Release CD' directory which anyone can access and do testing on the latest 'release'.
To be honest TFS build is a bit overboard for a small team like ours, and I only use it because its what I am used to.
In a previous company we used this http://www.finalbuilder.com/ and I can recommend it for ease of use and for the amount of software supported.
1) Build project with MSBUILD
2) FTP files to Production Environment
3) Copy / Paste manually to each web server
For intranet sites, we use CruiseControl in conjunction with SVN to have the site rebuilt automagically.
Theoretically you could extend this model over a VPN if you could map a drive remotely to a client's intranet. Or a more quick and dirty solution might be to use a tool like SyncBack to sync the remote folder containing the compiled DLLs for the site.
Deploy Web Applications Using the Copy Web Tool
Text from Microsoft Training Kit Book Web Based Development
Web Setup Projects are useful if you are providing a Web application to many users (for example, allowing people to download the application from the Web and install it). If you are responsible for updating a specific Web site for your organization, it’s impractical to log on to the Web server and install a Windows Installer package each time you make an update. For internal applications, you can edit the Web application directly on the Web server. However, changes you make are immediately implemented in your production Web application, and this includes any bugs that might be there. To enable yourself to test a Web application, you can edit a local copy of the Web application on your computer and publish changes to the production Web server using the Copy Web tool. You can also use the Copy Web tool to publish changes from a staging server to a production Web server, or between any two Web servers. The Copy Web tool can copy individual files or an entire Web site to or from a source Web site and a remote Web site. You can also choose to synchronize files, which involves copying only changed files and detecting possible versioning conflicts in which the same file on both the source and remote site have been separately edited. The Copy Web tool cannot merge changes within a single file; only complete files can be copied.