W3bbo said:Choose "File System" and have it export your website to some new directory in your filesystem.
Then inspect it to ensure everything's in order and present. Open up your web.config file and change things like connection strings and system-specific settings to match your host's, then upload it using an FTP client to the right directory within your webspace. The FTP client built-in to Windows Explorer shoud be fine.
Some hosts don't let you define custom application scopes, in which case you'll want to move the \bin directory and web.config file (assuming you're using "ASP.NET Web Applications" and not "ASP.NET Websites") to the root of your website's public folder (often called "public_html" or "htdocs") if your application won't exist in the root of your website.
As for your database, you'd use SSMS to connect to your host's SQL server and upload the bootstrap data into your database (in case they don't allow you to run a RESTORE you'll have to use DTS to restore the structure and do a batch import of data).
As for the stuff you've posted:
- The FTP option would work, but you don't get any second-chances to check what you're uploading. I'm not a fan of the Publish feature introduced in VS2005 which was added mainly for the benefit of beginners uses using VWD who wouldn't be familar with the "Web Applications" way of doing things. Note that the FTP client built-in to VS2008 doesn't support FTPS (FTP over SSL) or SFTP (SSH FTP).
- The "Remote Site" is just a byword for FPSE/WebDAV uploads. FPSE is de-facto deprecated now (the last version of FPSE was in 2002 and it doesn't offer any compelling reasons to install beyond making life simpler in the short-term for users of FrontPage). I understand that the "Remote Site" upload feature might work using plain-old WebDAV without FPSE, but very few hosts offer WebDAV as a means of managing website files. WebDAV is more secure than FTP because it doesn't send plaintext passwords.
- The Remote Site location would be a WebDAV address, which is a normal URL (e.g. http://www.mywebsite.com/webdav) except the server is configured to recognise the URL as being a webDAV-enabled location and so enables file management features. WebDAV is a powerful and underused/underrated feature, it's also the underpinning of SVN, which is testament to how good it is.
Right W3bbo. I could slog through all that. But wait I have a better idea. You are the person I need to do all of this in a flash--probably without even thinking twice--send me an email quoting a price to rent from you please to: pljprogrammer@live.com I am a poor Greek in a bankrupt country so any concession you could make on price would be greatly appreciated. I actually do have a guy I am using in the USA (he helped load one of my Silverlight apps, which ran for about a week before somehow the permissions changed on the folder it was running on and now it's inaccessible), and he's earnest, but lacks experience with programming and appears very overworked. I rather just use you. Also I need to be able to run databases on occasion in SQL Server Express. BTW I figured out a trick the other day where the database, though a trick in the connect string ("Data Source=|DataDirectory|UserData"), can reside in a subfolder in the folder your database app runs in, which makes maintainace easier I imagine because you don't have to copy the database into a central depository, but I digress.
You mention web config file, and once I did have to play with the switches and XML in one such file when I was doing a login page for ASP.NET, so I do have a vague understanding of the same, but below is a simple "Hello World" Web.config file, and as you can see it's quite complicated looking (to me). A lot of this stuff is signing off on your executables with a public key so they can't be spoofed I think, and other such stuff, but to me it looks pretty daunting. There's a gulf between theory and practice that you, having mastered both, can bridge. I myself was tickled pink the other day when I managed to build and then consume a 'web service' following an example in a textbook. But getting such a web service to run outside of localhost might be another matter (maybe not, with your help)?!
PJ
<?xml version="1.0"?>
<configuration>
<configSections>
<sectionGroup>
<sectionGroup>
<section requirePermission="false" allowDefinition="MachineToApplication"/>
<sectionGroup>
<section requirePermission="false" allowDefinition="Everywhere"/>
<section requirePermission="false" allowDefinition="MachineToApplication"/>
<section requirePermission="false" allowDefinition="MachineToApplication"/>
<section requirePermission="false" allowDefinition="MachineToApplication"/>
</sectionGroup>
</sectionGroup>
</sectionGroup>
</configSections>
<appSettings/>
<connectionStrings/>
<system.web>
<!--
Set compilation debug="true" to insert debugging
symbols into the compiled page. Because this
affects performance, set this value to true only
during development.
-->
<compilation debug="true">
<assemblies>
<add assembly="System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
<add assembly="System.Data.DataSetExtensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
<add assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3845AD364E35"/>
<add assembly="System.Xml.Linq, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
</assemblies>
</compilation>
<!--
The <authentication> section enables configuration
of the security authentication mode used by
ASP.NET to identify an incoming user.
-->
<authentication mode="Windows"/>
<!--
The <customErrors> section enables configuration
of what to do if/when an unhandled error occurs
during the execution of a request. Specifically,
it enables developers to configure html error pages
to be displayed in place of a error stack trace.
<customErrors mode="RemoteOnly" defaultRedirect="GenericErrorPage.htm">
<error statusCode="403" redirect="NoAccess.htm" />
<error statusCode="404" redirect="FileNotFound.htm" />
</customErrors>
-->
<pages>
<controls>
<add tagPrefix="asp" namespace="System.Web.UI" assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3845AD364E35"/>
<add tagPrefix="asp" namespace="System.Web.UI.WebControls" assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3845AD364E35"/>
</controls>
</pages>
<httpHandlers>
<remove verb="*" path="*.asmx"/>
<add verb="*" path="*.asmx" validate="false"/>
<add verb="*" path="*_AppService.axd" validate="false"/>
<add verb="GET,HEAD" path="ScriptResource.axd" validate="false"/>
</httpHandlers>
<httpModules>
<add/>
</httpModules>
</system.web>
<system.codedom>
<compilers>
<compiler extension=".cs" warningLevel="4">
<providerOption value="v3.5"/>
<providerOption value="false"/>
</compiler>
</compilers>
</system.codedom>
<!--
The system.webServer section is required for running ASP.NET AJAX under Internet
Information Services 7.0. It is not necessary for previous version of IIS.
-->
<system.webServer>
<validation validateIntegratedModeConfiguration="false"/>
<modules>
<remove/>
<add preCondition="managedHandler"/>
</modules>
<handlers>
<remove/>
<remove/>
<remove/>
<remove/>
<add verb="*" path="*.asmx" preCondition="integratedMode"/>
<add verb="*" path="*_AppService.axd" preCondition="integratedMode"/>
<add preCondition="integratedMode" verb="GET,HEAD" path="ScriptResource.axd"/>
</handlers>
</system.webServer>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity publicKeyToken="31bf3845ad364e35"/>
<bindingRedirect oldVersion="1.0.0.0-1.1.0.0" newVersion="3.5.0.0"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity publicKeyToken="31bf3845ad364e35"/>
<bindingRedirect oldVersion="1.0.0.0-1.1.0.0" newVersion="3.5.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>