Cannot create/reset deployment credentials on an Azure Web Site?

Issue

I encountered a problem recently, attempting to browse Azure Web Site using FTP access. What I was actually trying to do is getting my custom logs written down to App_Data. In order to get FTP access, I started to create an account for this, according to my own understanding and many instructions in the Internet.

Having typed a (valid) user name and (valid) password, I pressed the tick to confirm creation/reset. It led me to error message like this (Failed to Set Credentials with error: "Please, try again. If the problem persists, contact support."):

Furthermore, my just typed credentials did not appear in the Quick Glance:

As you can see, I used free mode, so I could not figure on Microsoft support, since they give only Billing support for free plans:

You know, I even started of grief to think about writing a temporary custom viewer of App_Data.

Cause

To be honest, I did not find out the actual reason why my deployment/FTP user was Not Set. I don`t even know whether this was a temporary problem or a permanent bug. But...

Solution (workaround)

In spite of the fact that you cannot create an account for FTP access, there is one. Moreover, you can easily find it under the nearest link, namely "Download publish profile":

This link will download the well-known file of *.PublishSettings, it can be opened with well-known notepad. Actually, it contains two sections, one of which (//...@publishMethod=FTP) includes the information we are looking for (search for the words selected as bold and red below at once in the notepad):

<publishData>
  <publishProfile 
      profileName="{pubName} - Web Deploy"
      publishMethod="MSDeploy"
      publishUrl="{pubUrl}.publish.azurewebsites.windows.net:443"
      msdeploySite="{pubName}"
      userName="${pubName}"
      userPWD="{generatedPassword 1}"
      destinationAppUrl="http://{pubName}.azurewebsites.net"
      SQLServerDBConnectionString=""
      mySQLDBConnectionString=""
      hostingProviderForumLink=""
      controlPanelLink="http://windows.azure.com">
    <databases/>
  </publishProfile>
  <publishProfile
      profileName="{pubName} - FTP"
      publishMethod="FTP"
      publishUrl="ftp://waws-prod-bay-001.ftp.azurewebsites.windows.net/site/wwwroot"
      ftpPassiveMode="True"
      userName="{pubName}\${pubName}"
      userPWD="{generatedPassword 2}"
      destinationAppUrl="http://{pubName}.azurewebsites.net"
      SQLServerDBConnectionString=""
      mySQLDBConnectionString=""
      hostingProviderForumLink=""
      controlPanelLink="http://windows.azure.com">
    <databases/>
  </publishProfile>
</publishData>

Surprisingly, these credentials did the work properly. Of course, if not to forget to turn on Passive Mode for FTP. Now we've got  the FTP access and reviewed the content of App_Data folder even in free plan.

UPDATE. It looks like some information about this has already appeared in the Internet.

Subversion 1.7, file & folders manipulation and Checksum mismatch error

Issue
In Subversion 1.6, we have got accustomed to manipulating working copy sub-directories as we wish, having a way to easily restore broken folder working copy. We performed it by deleting the problem folder and getting it fresh again by running svn update command.

After upgrading to 1.7, during such manipulation, we often encounter error like this:

svn: E155017: Checksum mismatch for 'D:\project\Aggregation\Service.cs':
   expected:  c446841fc97da2f6399ac77e334f2be2
   recorded:  0a896afb3a1923f11ef3794e2aae428b

Any attempt to remove folder and get it updated again does not fix the problem. Checksum mismatch appears on commit, revert or other operations with the working copy.

Cause
Subverion 1.6 stored the working copy cached repository information, like base revision files and their hashes, in every directory. Owing to this, a lot of folders .svn were located in the working copy, and we had to deal with them if we tried to copy or move parts of our working copy without exporting them. But this allowed such manipulation as I described above.

Subverion 1.7 stores this stuff in the working copy root only (for externals, it stores it in the root of an external working copy too).


Solution (workaround)
Instead of just deleting folder and then updating it, you perform a hack with the depth of the problem folder, setting it first to empty, then to infinity:


D:\project\Aggregation\> svn update --set-depth empty
D         Service.cs
Updated to revision 156.


D:\project\Aggregation\> svn update --set-depth infinity
A         Service.cs
Updated to revision 156.

It will remove the cached information about the problem directory from the working copy "cash-hash", and then restore it again with the actual information from the repository. So the error should disappear.

Related links

• http://glob.bushi.net.nz/glob/2007/02/14/subversion-checksum-mismatch-easy-workaround/

This link is about Checksum mismatch error too, but it seems to solve another problem, and not related to 1.6-1.7 upgrade issues.

here's how we check out a second copy of the relevant directory, and swap it in. optionally then copying over any other corrupted files etc. you may need to add salt or sugar to suit your specific situation (ie, in my example, there are no subdirectories blocked by the corrupted file)

1. PROBLEM: i can't check in the file 'lib/objects/blah.ext' because i get the error:
   

   svn: Checksum mismatch for '.svn/text-base/blah.ext'; expected: 'f8d45250f7df5561635854165862fdd8', actual: '644f85c4befa671150c5c6ec5fad9885'

Target framework for test project

Issue

After upgrading Visual Studio solution from 2008 (10.0) to 2010 (11.0) version, all test projects are automatically upgraded to using .Net Framework 4.0. If you try to set it to other values (3.5 or 2.0), it prevents this action by showing the following message:

---------------------------
Microsoft Visual Studio
---------------------------
Attempted re-targeting of the project has been canceled. You cannot change the specified .NET framework version or profile for a test project.
---------------------------
OK
---------------------------

Cause

Issue is reported to Microsoft Connect and closed as Won't fix. They did not explain why in the discussion, but I think this is due to some difficulty with Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll library compatibility.

Solution/Workaround

It works if you created your testing project by Visual Studio, but did not actually use VS testing engine and included other testing engine (e.g. NUnit). You just need to remove the guid for Test projects ({3AC096D0-A1C2-E12C-1390-A8335801FDAB} - see list) from ProjectTypeGuids property of the project file (*.??proj). This project type is not required for unit testing by other engines.

Otherwise, if you use Microsoft Visual Studio unit testing, try using some combination of workarounds described here.

Used links:

• INFO: List of known project type Guids (=>)
• Other solution (workaround - exclude from solution)
• More workarounds