For this installment in my series about FTP clients, I want to take a look at BitKinex 3, which is an FTP client from Barad-Dur, LLC. For this blog I used BitKinex 3.2.3, and it is available from the following URL:
At the time of this blog post, BitKinex 3 is available for free, and it contains a bunch of features that make it an appealing FTP and WebDAV client.Fig. 1 - The Help/About dialog in BitKinex 3. BitKinex 3 Overview
When you open BitKinex 3, it shows four connection types (which it refers to as Data Sources): FTP, HTTP/WebDAV, SFTP/SSH, and My Computer. The main interface is analogous to what you would expect in a Site Manager with other FTP clients - you can define new data sources (connections) to FTP sites and websites:Fig. 2 - The main BitKinex 3 window.
Creating an FTP data source is pretty straight-forward, and there are a fair number of options that you can specify. What's more, data sources can have individual options specified, or they can inherit from a parent note.Fig. 3 - Creating a new FTP data source. Fig. 4 - Specifying the options for an FTP data source.
Once a data source has connected, a child window will open and display the folder trees for your local and remote content. (Note: there are several options for customizing how each data source can be displayed.)Fig. 5 - An open FTP data source.
BitKinex 3 has support for command-line automation, which is pretty handy if you do a lot of scripting like I do. Documentation about automating BitKinex 3 from the command line is available on the BitKinex website at the following URL:
That being said, the documentation is a bit sparse and there are few examples, so I didn't attempt anything ambitious from a command line during my testing.Using BitKinex 3 with FTP over SSL (FTPS)
BitKinex 3 has built-in support for FTP over SSL (FTPS) supports both Explicit and Implicit FTPS. To specify the FTPS mode, you need to choose the correct mode from the Security drop-down menu for your FTP data source.Fig. 6 - Specifying the FTPS mode.
Once you have established an FTPS connection through BitKinex 3, the user experience is the same as it is for a standard FTP connection.Using Using BitKinex 3 with True FTP Hosts
True FTP hosts are not supported natively, and even though BitKinex 3 allows you to send a custom command after a data source has been opened, I could not find a way to send a custom command before sending user credentials, so true FTP hosts cannot be used.Using Using BitKinex 3 with Virtual FTP Hosts
BitKinex 3's login settings allow you to specify the virtual host name as part of the user credentials by using syntax like "ftp.example.com|username" or "ftp.example.com\username", so you can use virtual FTP hosts with BitKinex 3.Fig. 7 - Specifying an FTP virtual host. Scorecard for BitKinex 3
This concludes my quick look at a few of the FTP features that are available with BitKinex 3, and here are the scorecard results:Client
That wraps it up this blog - BitKinex 3 is pretty cool FTP client with a lot of options, and I think that my next plan of action is to try out the WebDAV features that are available in BitKinex 3. ;-)(Cross-posted from http://blogs.msdn.com/robert_mcmurray/)
I was recently creating a new authentication provider using FTP extensibility, and I ran into a weird behavior that I had seen before. With that in mind, I thought my situation would make a great blog subject because someone else may run into it.
Here are the details of the situation: let's say that you are developing a new FTP provider for IIS, and your code changes never seem to take effect. Your provider appears to be working, it's just that any new functionality is not reflected in your provider's behavior. You restart the FTP service as a troubleshooting step, but that does not appear to make any difference.
I'll bypass mentioning any other troubleshooting tasks and cut to the chase - if you read my Changing the Identity of the FTP 7 Extensibility Process blog post a year ago, you will recall that I mentioned that all custom FTP extensibility providers are executed through COM+ in a DLLHOST.exe process. When you restart the FTP service, that should clean up the DLLHOST.EXE process that is being used for FTP extensibility. However, if you are developing custom FTP providers and the DLLHOST.EXE process is not terminated by the FTP service, you may find yourself in a situation where you have a DLLHOST.EXE process in memory that contains an older copy of your provider, which will not be removed from memory until the DLLHOST.EXE process for FTP extensibility has been forcibly terminated.
If you have read some of my earlier blog posts or walkthroughs on IIS.NET, you may have noticed that I generally like to use a few pre-build and post-build commands in my FTP projects; usually I add these commands in order to to automatically register/unregister my FTP providers in the Global Assembly Cache (GAC).
With a little modification and some command-line wizardry, you can automate the termination of any orphaned DLLHOST.EXE processes that are being used for FTP extensibility. With that in mind, here are some example pre-build/post-build commands that will unregister/reregister your provider in the GAC, restart the FTP service, and terminate any orphaned FTP extensibility DLLHOST.EXE processes.
Note: The following syntax was written using Visual Studio 2010; you would need to change "%VS100COMNTOOLS%" to "%VS90COMNTOOLS%" for Visual Studio 2008 or "%VS110COMNTOOLS%" for Visual Studio 2012.
net stop ftpsvc
cd /d "$(TargetDir)"
gacutil.exe /uf "$(TargetName)"
for /f "usebackq tokens=1,2* delims=," %%a in (`tasklist /fi "MODULES eq Microsoft.Web.FtpServer.*" /fi "IMAGENAME eq DLLHOST.EXE" /fo csv ^| find /i "dllhost.exe"`) do taskkill /f /pid %%b
gacutil.exe /if "$(TargetPath)"
net start ftpsvc
The syntax is a little tricky for the FOR statement, so be carefully when typing or copying/pasting that into your projects. For example, you need to make sure that all of the code from the FOR statement through the TASKKILL command are on the same line in your project's properties.
When you compile your provider, Visual Studio should display something like the following:
------ Rebuild All started: Project: FtpBlogEngineNetAuthentication, Configuration: Release Any CPU ------
The Microsoft FTP Service service is stopping.
The Microsoft FTP Service service was stopped successfully.
Microsoft (R) .NET Global Assembly Cache Utility. Version 4.0.30319.1
Copyright (c) Microsoft Corporation. All rights reserved.
Assembly: FtpBlogEngineNetAuthentication, Version=18.104.22.168, Culture=neutral, PublicKeyToken=426f62526f636b73, processorArchitecture=MSIL
Uninstalled: FtpBlogEngineNetAuthentication, Version=22.214.171.124, Culture=neutral, PublicKeyToken=426f62526f636b73, processorArchitecture=MSIL
Number of assemblies uninstalled = 1
Number of failures = 0
SUCCESS: The process with PID 12656 has been terminated.
FtpBlogEngineNetAuthentication -> C:\Users\dude\Documents\Visual Studio 2010\Projects\FtpBlogEngineNetAuthentication\FtpBlogEngineNetAuthentication\bin\Release\FtpBlogEngineNetAuthentication.dll
Microsoft (R) .NET Global Assembly Cache Utility. Version 4.0.30319.1
Copyright (c) Microsoft Corporation. All rights reserved.
Assembly successfully added to the cache
The Microsoft FTP Service service is starting.
The Microsoft FTP Service service was started successfully.
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========
If you analyze the output from the build process, you will see that the commands in my earlier samples stopped the FTP service, removed the existing assembly from the GAC, terminated any orphaned DLLHOST.EXE processes, registered the newly-built DLL in the GAC, and then restarted the FTP service.
By utilizing these pre-build/post-build commands, I have been able to work around situations where a DLLHOST.EXE process is being orphaned and caching old assemblies in memory.(Cross-posted from http://blogs.msdn.com/robert_mcmurray/)
The need to diagnose and troubleshoot application’s failures often comes up during deployment to a hosting environment. Some configuration settings in hosting server may differ from what application expects. Often it is not as easy to figure out the cause of the problem in a hosting environment as it is on a development machine. I found the following techniques useful when troubleshooting errors in PHP applications hosted in Windows Azure Web Sites.1. phpinfo()
This is the most obvious, but very often the most helpful diagnostics tool. The output of this function provides a lot of information about the PHP runtime. Use it to determine what PHP extensions are enabled, what are the PHP configuration settings and what values are stored in server environment variables.
To use the phpinfo() function create a new php file that contains just one line:<?php phpinfo(); ?>
Name this file with some non-obvious name (don’t name it phpinfo.php) and upload it to the root directory of your site. Request this file from a web browser and analyze the output.
The output from phpinfo may expose security sensitive information! Always delete this file from the site’s root directory after you are done with it.2. wincache.php
WinCache extension is by default enabled for PHP web sites. To check how opcode and user cache work and what is the current content of the cache use wincache.php script that can be downloaded from the wincache source code repository. Get the script and the edit it by specifying the user name and password that will be used to protect the access./** * ======================== CONFIGURATION SETTINGS ============================== * If you do not want to use authentication for this page, set USE_AUTHENTICATION to 0. * If you use authentication then replace the default password. */ define('USE_AUTHENTICATION', 1); define('USERNAME', 'someusername'); define('PASSWORD', 'somepassword');
After that upload it to the root directory of a website and request this page from a web browser. The output will look similar to below:
Always protect the wincache.phpscript by using the built-in authentication or other authentication mechanisms. Leaving this script unprotected may compromise the security of your web application.3. PHP Error Log
PHP runtime in Windows Azure is configured to save application errors into a log file located in the /LogFiles directory under FTP root of a site.
If application does not work or returns a blank page – check this file as it may contain the details of an error. I also check this file from time to time for my live sites to make sure the site is running properly.
It is also possible to overwrite the default location of the error log file. For that create a file called .user.ini and add the following line to it:error_log=D:\Home\site\wwwroot\php_errors.log
Upload this file to the root directory (wwwroot) of your web site.4. PHP display_errors
PHP runtime directive display_errors is used to output the errors in the HTTP response. For production deployments it should be set to “Off” in order to not show error details to web site visitors. For development and debugging purposes you can temporary set it to On by using .user.ini file:display_errors=On html_errors=On error_reporting = E_ALL
When application has an error it will be output in the web browser.
I usually turn display_errors off as soon as I got all the necessary information from the error output.5. HTTP logs, Detailed Error Messages, Failed Request Tracing
By default HTTP logging, detailed error messages and failed request tracing are turned off for a site. To turn them on use the CONFIGURE page in Windows Azure Portal:
Once enabled the log files will appear in the following directories under site’s FTP root:
Xdebug is a very popular PHP extension that helps with debugging and profiling of PHP scripts by providing a lot of valuable debug information. To enable Xdebug for a site in Windows Azure download the appropriate build of Xdebug extension from downloads page. If your site uses PHP 5.3 then download “5.3 VC9 (32 bit)”. If your site uses PHP 5.4 then download “5.4 VC9 (32 bit)”. Use 32 bit build even if your Windows OS is 64 bit. Do not use thread safe (TS) builds.
Upload the php_xdebug_####.dll file to /site/wwwroot/bin directory. If bin directory does not exist then create it. After that use the CONFIGURE tab in Windows Azure Portal to enable xdebug extension:
With xdebug enabled you will be getting more detailed error messages and call stack:
ClearDB service that provides MySQL database hosting is now integrated into the Windows Azure Portal. It is now possible to buy and manage your MySql databases from the portal. Also the billing is integrated, meaning that ClearDB charges will be billed on Azure subscription.
To access ClearDB management page use the ADD-ONS tab.
From there you can open the ClearDB query performance page as well as access other database management information
I wonder why the query performance chart shows such a light load on my database. I guess this maybe because of a wincache user cache which loads all the blog content in memory so there are very few or none database access operations.