Since the updated version of Azure PowerShell (0.9.7) was released on August 14th 2015, I'm getting the following error whenever I run New-AzureHDInsightCluster or Get-AzureHDInsightJobStatus. Both worked without issue before installing the new release. Any ideas?
Validating connection to 'storageacct.blob.core.windows.net' failed. Inner
exception:Could not load file or assembly 'Microsoft.WindowsAzure.Storage, Version=3.0.3.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
The new PowerShell release uses Azure Resource Manager mode instead of Azure Service mode. For more information on the ARM mode, see https://azure.microsoft.com/en-us/documentation/articles/resource-group-overview/ and https://azure.microsoft.com/en-us/documentation/articles/powershell-azure-resource-manager/
First you need to decide which mode to use. Either way, I would recommended to use the following cmdlet to confirm the mode you are in:
Switch-AzureMode AzureResourceManager
The following article shows you how to provision a cluster using the ARM mode.
https://azure.microsoft.com/en-us/documentation/articles/hdinsight-provision-clusters/#provision-tools
Related
Where can I download the latest version of Microsoft.TeamFoundation.DistributedTask.Task.Deployment.dll for a release on Azure DevOps?
Microsoft-hosted agents are regularly updated to make sure the latest and applicable images of the softwares are applied to the agents.
If you want to use the latest version of softwares to run the related pipeline tasks on DevOps,you can install the latest softwares on the agents which you used .
If the agent you used is privated agent, you need to manually install or upgrade all the softwares you request on the agent machine.By downloading the latest package from Internet or using the related commands to install/upgrade the softwares.
You can refer to this case for details.
For other SO users could get clearly know more details about this issue when they are checking to this ticket, I add the following ticket which relevant with this ticket:
SO forum: Register-Environment Failing
DC forum: Where to download latest versions of deployment utilities for azure pipeline tasks?
When you using the task(such as AzureFileCopy V1.*) which need/import the Microsoft.TeamFoundation.DistributedTask.Task.Deployment.dll file, no matter whether the agent you used is hosted agent or private agent, its version are always be the latest version to the task, because these dll files are all exists depend with task.
According to the content you shared in the DC forum ticket:
I suspect that there's a newer version of these with a newer version
of Register-Environment, because with my version of this PowerShell
module, the following line fails claiming that I'm missing parameters,
specifically a "taskContext."
the error you are facing caused by the configuration of the Microsoft.TeamFoundation.DistributedTask.Task.Deployment.dll file. We did not defined the parameter taskContext in it.
To check and verify it, you can execute the PowerShellOnTargetMachines v2.* task in your private agent, then find the dll file in the path of ~\_work\_tasks\PowerShellOnTargetMachines_3b5693d4-5777-4fee-862a-bd2b7a374c68\2.0.7\DeploymentUtilities. And also, you can see its version is 16.0.0.0.
Then you can use decompile tool, here what I am using is Reflector, to decompile this dll file.
You can see that in the script block of RegisterEnvironmentCmdlet, there does not have parameter taskContext defined in it.
When you use PowerShellOnTargetMachines v2.* task, the parameter for Register-Environment supported only include EnvironmentName, EnvironmentSpecification, UserName, Password, WinRmProtocol, TestCertificate, ResourceFilter, ProjectName, TagsList.
For the parameter taskContext, it is the one which only used in v1.*(See v1.* source code) and does not supported in v2.*. In v1.*, taskContext used for Get-VssConnection cmdlet which dose not used any more in v2.*. That's why you facing the error message in PowerShellOnTargetMachines v2.* task.
I'm using Visual Studio Online's build tools to deploy web applications from a single solution. I've occasionally been running into file locking issues.
Error: Web Deploy cannot modify the file 'Microsoft.CodeAnalysis.CSharp.dll' on the destination because it is locked by an external process.
After some Googling, I believe the "fix" is to stop the web applications before deployment on Azure and start it back up after. Sounds legit.
However, there does not seem to be a straight forward way to do this directly on VSO's build definitions. I've created an "Azure Powershell" build task, but it wants a PS1 file from the repository. It doesn't seem to let me just run Azure Powershell commands (e.g. Stop-AzureWebsite) from here. My team has created a work-around where we have a "run.ps1" that just executes the command you pass as a parameter, but none of us are satisfied by that.
What are we missing? There has got to be an easier way to do this without having a PS1 script checked into source control.
I solved this by installing Azure App Services - Start and Stop extension from Visual Studio Marketplace.
When installed, it will allow you to wrap the Deploy Website to Azure task in your Release definition with Azure AppServices Stop and Azure AppServices Start tasks, effectively eliminating the lock issues.
Check if you are using "/" on the "Web Deploy Package" path for folder separators instead of "\".
i.e. change
$(System.DefaultWorkingDirectory)/My Project/drop/MyFolder/MyFile.zip
for
$(System.DefaultWorkingDirectory)\My Project\drop\MyFolder\MyFile.zip
I noticed that was the only difference between the one I was getting the error and the others (the Restart step I added was not helping). Once I modified the path, I got it working.
Sounds crappy, but fixed my issue.
Did you use the Build Deployment Template that sets the correct msbuild parameters for you for your package? You can see how here. I would create a build using that template and see if you have the same issues. If so ping me on Twitter #DonovanBrown and I will see if I can figure what is going on.
As a rule it is good practice to have any scripts or commands required to deploy your software to be checked into source control as part of your build. They can then be easily run repeatedly with little configuration at the build level. This provides consistency and transparency.
Even better is to have deployment scripts output as part of the build and use a Release Management tool to control the actual deployment.
Regardless having configuration as code is a mantra that all Dev and Ops teams should live by.
I'm using the official virtocommerce azure deploy script under folder "virtocommerce\src\Extensions\Setup\VirtoCommerce.PowerShell" to deploy virtocommerce(with azure tool v2.4), i encounted some problems while running "deploy.ps1" script in windows azure powershell
In "azure-db.ps1", there's lot of syntax like "Get-Date –f" , the dash character is wrong ,"–" must be "-", otherwise you will get error.
In "azure-deploy.ps1", there's a function "build-search" which use cspack.exe to create "ElasticSearch.cspkg",that's correct, but for other packages such as "CommerceSite.cspkg" and "AzureScheduler.cspkg", i did not found any functions to create those packages, this will lead to an error says "CommerceSite.cspkg" can not be found.
Does anybody has the same problems?
Turn out that there's some problem inside code:
"deploy.ps1" script is using deploy-tfs.ps1 , and use parameter "$build".
parameter "$build" has been reset to 'False' in "deploy-tfs.ps1"
"azure-deploy.ps1" using "$build" to decide if it's need to build the azure package, and this parameter is always 'False', so the azure package will never be creat.
The script is designed to run on azure sdk 2.4, not 2.5. The script is used to deploy daily both demo and testing environments and were completed succesfully today. You can see the status here: https://virtocommerce.codeplex.com.
As for cspkg, it is generated during actual build, by msbuild. The elastic search ccspkg has to be created differently, as it has to include javaruntime in addition to elasticsearch runtime and packaged into a single setup.
The new, 1.13 version of Virto Commerce by default deploys azure website instead of azure cloud service for website and scheduler (deployed as a web job). Only elastic search is deployed as a cloud service. The setting can be changed in deploy.ps1.
Also make sure to check the complete instructions on how to deploy source code to azure at http://docs.virtocommerce.com/display/vc1devguide/Source+Code+Azure+Deployment.
Have a Visual Studio 2010 application that use Entity Framwork to bind controls. After publishing the application to IIS 7.5, I get the following error stack trace message.
This does not happen when run local!
System.IO.FileNotFoundException: Unable to resolve assembly 'nameOfDll'.
After many hours and days of research and following all suggestions, the error still is rendered.
I made sure that all references were loaded locally and set CopyTo: to true for each reference. The only other suggestion was to set the ContextTypeName in the EntityDataSource definition. I am not certain the correct value to enter.
I have also encountered this on IIS 6.0.
You will often get this type of error when there is a version or culture mismatch for a DLL where a specific version and/or culture is demanded.
Use the Fusion Log Viewer (Fuslogvw) to log binding errors. NOTE: You must run it as Administrator or it will silently fail to log.
http://msdn.microsoft.com/en-us/library/e74a18c4(v=vs.110).aspx
The output of Fuslogvw will tell you exactly what attempts were made to satisfy binding requests, and why they failed.
If this is in an environment where you can do so, stop IIS, start Fuslogvw, start Fuslogvw logging, then start IIS again and browse to the problematic website. If you cannot stop IIS, I believe it should be sufficient to recycle the relevant application pool with Fuslogvw running and logging.
We get the following error when we add and deploy a wsp in sharepoint 2010.
Add is successful.
Deploy to a particular web-application gives this error:
Error: The copying of this file failed: Feature.xml.
Type 'System.Security.Principal.WindowsImpersonationContext' in Assembly 'mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' is not marked as serializable.
The wsp has about 5 features. Looking at the ULS log viewer we were able to figure out that the error occurs when the feature.xml belonging to the first feature (first in alphabetical order) is getting deployed. Removing this feature, repackaging and redeploying does not help still. This time, the deployment fails with the second feature (which is now first in alphabetical order, because the former was removed).
The wsp is deployed with the user who is a farm administrator.Its a farm solution.
The deployment was tried using stsadm/Powershell/Central admin UI and failed in all three cases with the same error.
What is weird is, the same wsp successfully deploys in another 2010 machine(which happens to be our dev machine), but fails in our test environment.
Any ideas?