I have now a working Website that I have deployed to the IIS on my local machine using Visual Studio 2013. I can access the website successfully from other machines in my office and in neighboring offices. I have even had others check the access from geographically remote locations, and still been successful. The access method is to put my machine's IP Address and add the name of the application, ###.###.###.###\name, into the address bar of a browser.
The next step is to promote it to production. We are not using Azure, so the tutorials for promotion to production I have found aren't useful, nor are we using 3rd party providers.
The method I have conceived is as follows:
Have an admin directly login into a company server
install the database software
install Visual Studio
install IIS
copy the local machine's db to the server db
copy the locally deployed files to the server
admin login into Visual Studio
deploy the site on the server in the same way it was deployed on the local machine
use the server IP or update the host file on all networked computers to map the IP to an appropriate name (or the local network has a local DNS we can update)
This would allow me a DEV environment (the VS IDE), a TEST env (locally deployed version), and a PROD env (the version deployed on the server).
I don't see any reasons why this wouldn't work, maybe a bit tedious, but workable.
Is this method ok? Am I missing anything critical?
No, this is an altogether inappropriate way to push a build to a production environment.
Your source code should be stored in a source code repository. You should have an automated, continuous build server pull from the repository and complete the build in a dedicated environment that is itself under change control. The build should include the generation of installation files, e.g. a click-once deployment package. From there you can have an admin run the deployment package, or, ideally, you'd push it automatically with a tool like Octopus.
The above, honestly, is the bare minimum for a commercial web site. There is much, much more you can do to make things even more robust, e.g. blue-green deployment.
Note that none of this involves installing development tools like Visual Studio on your server. The server should stay as clean as possible, running the fewest applications that you need, to minimize any sort of attack surface and to keep the machine running efficiently.
Dont Put Yours Machine IP, Decompilers Can Take It And BruteForce Your IP To Remote Acess Your Machine.
Related
I need some help here. I have a website in asp.net and a database in my local machine, and I'm setting up a testing enviroment so that I can access the site and the database from outside the local network and make tests. I want to set up a server in my windows 10 using IIS to publish the site, and I already know how to publish a asp.net site through Visual Studio and IIS manager. My only issue now is to make it available outside my network. Is there a easier way of doing this than having to buy a domain and a hosting service?
You could create a free azure app:
https://azure.microsoft.com/en-gb/pricing/calculator/#app-service1
You can run a single website (asp.net) and not need to register a domain it will give you a link publicly available on the web.
Whoops, sorry, the database wouldn't be free however the basic version is not expensive. This is in fact what I run for my own test cases.
In order to host at home, you would need to ensure that you had a static IP address and that port 80 was opened to allow traffic in and out.
https://serverfault.com/questions/1058/how-do-i-set-up-a-web-server-out-of-my-home
A little background (before I get downvoted to oblivion!)
I'm working on an intranet-hosted ASP.NET web application in a highly secure environment. At the moment it's deployed by building a package in Visual Studio, the zip file is copied onto the server and installed in IIS using WebDeploy (right-click -> Deploy -> Import Application).
What I'd like to do is deploy a sanitised version of this application to an Azure Web Site for demonstration purposes, however most of the standard Azure deployment methods do not apply to me because:
I work on a secure network so Visual Studio is blocked from connecting to Azure (rendering 95% of documentation irrelevant!)
installable software is strictly controlled on this network so I cannot install the Azure SDK needed to create Service Definitions, Configurations and Packages
The only machine I have access to which can connect to Azure is woefully underpowered and can only run puTTY, PowerShell and basic text editors.
At the moment, I have a Windows VM in Azure just running IIS and WebDeploy - this works but seems like overkill (and a good way to burn through my credit) when Web Apps in theory do everything I need.
What can I do?
Another option may be to checkin the WebDeploy package to a free subscription of Visual Studio Team Services (VSTS = TFS in the cloud) and then create a deployment pipeline in VSTS using the new Release Management features.
https://www.visualstudio.com/features/release-management-vs.aspx
in that case:
1) FTP from your machine using your own FTP client or i would recommend to use PSFTP from Putty package.
2) Still WebDeploy, but use that to generate the needed files, then you can use PowerShell like that.
You can also use https://www.microsoft.com/web/webmatrix/ to connect to azure websites. It works with HTTP, only problem could be a corporate proxy.
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
Our production website is available via our Local LAN. Since it's been available, I've used File System deployment to move our site into production. I know Web Deploy has been available for some time, but with the release of VS2012, I'm wondering if there are specific advantages of using Web Deploy over File System, keeping in mind that we are publishing over a 1Gbps connection. Also, I don't use any of the database updating features of Publishing.
It's really whichever you like better. I've tried out both and don't see any real advantages which would make one superior
I'm basically wondering what the best way to deploy an Asp.Net Web Site is, mostly from the point of view of security. Right now, I'm trying to publish the website using Visual Studio 2010. Could someone direct me to a good tutorial on how to do this securely? For example, can it be done over an encrypted connection via Visual Studio? Is it necessary to install any software on the server to do this? Should I use a different program to open up an SSL (TLS) connection first, and if so, which program (does it come standard with windows)?
The server is running Windows Server 2008. Development is on Vista.
Many thanks in advance for any direction in this matter!
Andrew
I would publish the site to your local machine and file copy the files across to your test/production environment. As a rule we don't publish sites straight from VS to test or production.
For example you don't want to accidentally push things straight from dev into a live environment do you?
As far as the file transfer security goes you could use SFTP.
Note: First thing is to check with the owner of the server, as they often will provide you an FTP connection and will take care of configuring IIS.
If you want to add security, make a keyfile and sign your assemblies and consider running Dotfuscator on your dlls, the community edition is included in Visual Studio. Here is an earlier question where I've put more info on Dotfuscator.
If you have to do the deployment yourself, here's a few things to consider.
XCopy (easy)
MSI (have to create a setup program, you can do this easily in Visual Studio)
There is no security advantage in deploying using Visual Studio, but you can use Visual Studio to create a small setup program. One thing you want to make sure for security is DO NOT deploy any .cs files. Prepare your files, you should compile in Release mode, make sure debug is not enabled in your config file, keep your bin and it's dll, also the aspx, asmx, ascx, svc, css, js, and config files.
XCopy: Install a small FTP server, or use one your company alreayd has, this will allow you to get your files once you are logged into the target machine. You should be able to get an administrator account for the target machine, just ask the sysadmin of the domain, then log on using remote desktop, got to your ftp site, and download your files. Open IIS on the target machine, create a virtual directory and a pool. Copy your files to the location, configure your connection string to your DB if you use one, then test your website.
MSI: same process as above, except the setup will create the virtual directory and pool for you.
Here is extra info on best practices from the official ASP.Net website.
If you have some control on the server (e.g. to configure IIS7), you might want to look into Microsoft Web Deploy (new product just been released):
http://weblogs.asp.net/scottgu/archive/2010/09/13/automating-deployment-with-microsoft-web-deploy.aspx
Haven't tried it myself, but looks quite slick and it apparently encrypts the data being copied up, so might suit you.