In order to improve the deployment / build process of my ASP.NET app, I would like to make a .bat that
builds the current solution in release mode
xcopy the files to a remote server
Creating a release build via command line is easy.
But how can I xcopy the files to the remote server?
I think I have to map the remote destination to a network drive (?). However I could not connect to the remote server, although I have enabled file sharing for the folder on the server. Maybe the firewall is blocking the request? Which port should I open? Or is there another solution?
EDIT
Thanks for all the answers so far, but I probably need a step by step guide on how to set up the folder sharing on the server. I shared the folder, I opened up port 445 so that I can connect to the server but still, I cant connect from my local machine to the server in order to map the network path to a system drive.
Since you are deploying a ASP.Net site, I am assuming that you are in a windows environnement (isn't smart ? :)).
SO ! Forget about .bat and go for POWERSHELL !
Anyway, this is not point of your question...
To copy to a remote folder you should have the rights to do so on the Remote computer.
Check if you have the same account on your local computer and on the remote one.
For instance, if you are logged on your local computer in the domain "Work" with the login "Pipo", you must give the rights to this account to write into your special folder on the remote computer.
You can achieve that with a right click on the folder, security options, and then selecting the correct identity.
Here is a step-by-step guide:
http://support.microsoft.com/kb/301281
It might be worth moving the files with XCOPY via a UNC path
\\machine\folder
That will require you to have access to folder from the originating server. Check that the folder has been shared and that the relevant read/write permissions have been granted.
If the server is on your local network, I'd suggest using robocopy instead of xcopy - it has many more useful options and capability to retry on errors. It handles UNC names just fine (as I believe xcopy does too). I think it's available on newer Windows clients - if it's not on your machine Google for it - it's available in various resource kit downloads (I don't know the details of if/when Microsoft started including it in the OS distribution because I've had it in my utility kit for a long, long time now).
If the server isn't local, you can script the command line FTP client to perform the transfer. If you need additional flexibility or security there are many other file transfer options, including WinSCP.
Of course in either case (local or remote server), the server's permissions and your authentication needs to be set up properly for this to have a chance to work.
You can use any UNC path: \\machine\sharedFolder. If you don't want to set up a shared folder, you can reference any of the drives on the machine using a $ sign: \\machine\c$\program files\etc. If your machines are in Active Directory, or if you have a local user on the target machine with the same username AND password Windows will handle the authentication seamlessly.
Have you tried unleash it?
http://www.eworldui.net/unleashit/
It can move files across networks, run pre build bat files, file masking, etc...
I used to use it before on .net 1.1 projects.
I think you want:
XCOPY c:\myproject\build\*.* \\server\\build\ /S /E
All of the above seem to be grand answers - you could look at using an msbuild script and the msbuild community tasks to do all of this - they can zip up your build and ftp it to a remote server.
I've just set this up for one of our sites, took a couple of hours to get my head around it, but it builds the site in release, updates the config files for production, removes unnecessary files and then does the upload.
after looking for so many answers here is the solution
"xcopy D:\\folder\\container \\\\servername\\folder\\container\\ \/E \/H \/Y"
Related
I have a problem - I cannot find my file when I open it using http://localhost:49652/.well-known/acme-challenge/FfI7Xeq7_QH5R5pCd3LhAkU4k3nOqBz9mNbvJ9EwMoQ although it exists and the path is correct.
I use ASP.NET C#, OS: Windows Server 2012 And IIS 8.0.
And error:
Help me... Please!
I want to forward you to an other question: What file extensions are blocked by default in IIS
The issue is that IIS has a configuration, how to handle requested files.
Depending on the extension, there have to be done different actions: While resources like .txt or .jpg files are just sent into the network as they are stored on the disk, other files like .aspx or .asmx have to be parsed, executed in dotnet and then the output have to be sent etc.
Other extensions like .dll or .exe are blocked by default, I think.
The problem is, that your files do not have any extension, so for this directory you have to configure that IIS should pass through all of the files.
Found another usefull link to microsoft: https://learn.microsoft.com/en-us/iis/configuration/system.webserver/security/requestfiltering/fileextensions/
I want to update my website by extracting a zip file which contains whole files of the website itself. Apparently the system does not allow me to do this as such folders are protected:
Error while extrating: Access to the path
'C:\WebsiteFolder\Website\bin\' is denied.
I also think that changing the dlls will restart the server while extracting. Is there a way to do this? To extract all files then restarts the server after it finishes. Also the web.config might be overwritten while extracting the zip file.
Does putting offline.htm help?
This is because IIS is using files within the bin directory, and the AppPool is likely running as system, or an administrator account.
Stopping IIS (or the app pool) will enable you to replace the files.
I also think that changing the dlls will restart the server while extracting
Yes, it will restart the app pool when you change these files
I'm trying to make an uninstaller.
I basically need to be able to remove a directory in the program files that contains the uninstaller.
I was thinking to have the uninstaller create a copy of itself to the temp folder,
then have the uninstaller running from the program folder open the uninstaller in temp and close itself where it continues the uninstall.
Problem is, how do I delete the uninstaller in the temp folder...
Check out: https://www.catch22.net/tuts/win32/self-deleting-executables
He has multiple solutions - but mostly aimed at C++ code.
I am currently trying to implement the "DELETE_ON_CLOSE" method in C#.
A comment to all the nay-sayers: MSI does not solve this problem in all cases. In my case, my application needs to install to a network folder, where any network user can run the app. It also needs to support upgrades and uninstalls from any network workstation - not necessarily the same workstation that installed the app. This means I cannot register an Uninstaller into the Add/Remove Programs list on the local machine. I must create an Uninstall.exe that is dropped into the install folder. MSI does not support that, so I have to write my own.
Even though I agree with everyone saying you shouldn't do that, what you can do is:
Have your program create an executable (and config file) in the temporary folder of the OS it's working on.
Have your program start it as an independent process, then exit.
That executable then calls back the actual setup stuff.
Once the setup is done, the temporary executable can delete the setup files.
Since the only trace of your program is now in the temp folder, it will eventually get cleared automatically.
I have an odd bug where my code returns a file not found exception but the file seems to be exactly where it should be. My project has some code to run a system cmdlet and look for the results of the cmdlet in an XML output file. We tell the cmdlet to put this output XML in a custom subdir of the system TEMP dir, e.g., C:\WINDOWS\TEMP\SomeFolder\output.xml. We then use the .NET XmlDocument class to open and parse the XML file.
On WinXP, this works. On my dev box, this works. On a clean Win7 test machine, it does not.
My first thought was that I'm running into Vista/Win7 File Virtualization, but our application manifest specifies that our app run as Admin -- and from what I've read, that should bypass file virtualization.
The other wrinkle is that our code likes to use UNC file paths, even if the file is local to the machine. (We have a requirement that the code in question may need to run the cmdlet on a remote machine, and therefore the output XML could be on a remote machine too.) So we try to open the XML file via \MATT-WIN7\C$\WINDOWS\TEMP\SomeFolder.xml rather than C:\WINDOWS\TEMP\SomeFolder\output.xml.
But I removed the UNC path code temporarily and a simple call to File.Exists() still says the XML file is not there, when Windows Explorer shows the file sitting exactly where I think it should be.
Is there some nuance of file virtualization that I have not read about yet?
My workaround is to move the output xml file somewhere else, but that will potentially break the "portability" of our code when it needs to run on a remote machine, because using the %TEMP% location is a location that can be resolved for remote computers pretty easily (via remote registry call to find the system environment variable).
I would prefer to leave the file where it is, and fix our code so it actually finds the file!
There is a user-specific override for the %TEMP% environment variable that points to %USERPROFILE%\AppData\Local\Temp, not to %SYSTEMROOT%\Temp. Make sure your code is looking in the temp folder you expect it to look at.
Update: Based on your comments, it seems that the problem is that your app is not actually being elevated on the test machine, but is elevated on your dev machine. I suspect the following:
you either have UAC disabled on your dev machine or you are running VS as administrator. Big no-no on both. :-)
your binary is not code-signed and is not in one of the two trusted locations - %SystemRoot%\system32 or %ProgramFiles%. For security reasons UAC does not even prompt the user for elevation for apps that have elevation manifest, but are not code-signed or in a trusted location.
You can create a self-signed certificate to code-sign your binary and add that certificate to the test machines, to get the UAC prompt. Once you've confirmed that your app is properly being elevated, your code to access the system %TEMP% folder should work correctly.
I'm running an application from a network share, this application then try to verify if the path "C:\temp" exist and return true or false.
If the code is runned localy, there's no problem. If it's runned from a network share, I get the result false, even if the folder exist localy.
The code is C# on framework 2.0
Thank you
You would need to run under elevated priviledges to see this. It part of the Code Access Security model.
I would recommend using an application data folder as returned by Environment.GetFolderPath instead of a hard-coded path.
This has to do with the security policy settings of the .NET framework. By default, code running from the intranet zone (which UNC path are assigned to) are not fully trusted, limiting some of your code to succeed.
You can use the configuration wizards to change these settings if required. Open a Visual Studio command prompt and run "Configwizards.exe".
See also this link for information about CAS configuration.