When I try to publish my Service Fabric application to a Azure cluster I get the following error message:
3>Copy-ServiceFabricApplicationPackage : Operation timed out.
3>At C:\Program Files\Microsoft SDKs\Service
3>Fabric\Tools\PSModule\ServiceFabricSDK\Publish-NewServiceFabricApplication.ps1:230 char:9
3>+ Copy-ServiceFabricApplicationPackage -ApplicationPackagePath ...
3>+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3> + CategoryInfo : OperationTimeout: (:) [Copy-ServiceFabricApplicationPackage], TimeoutException
3> + FullyQualifiedErrorId : CopyApplicationPackageErrorId,Microsoft.ServiceFabric.Powershell.CopyApplicationPackage
3>
3>Finished executing script 'Deploy-FabricApplication.ps1'.
3>Time elapsed: 00:12:45.2589165
Apperently there is a hard-coded 10 minute timeout in the publish script as you can read here: https://github.com/Azure/service-fabric-issues/issues/10
This timeout will be removed in an upcomming release, but in the mean time what are my options? Is there a way I can publish my application service by service?
Any suggestion is welcome!
I've solved this by having a virtual machine running in azure. I've installed Visual Studio 2015 community and the service fabric SDK.
I then use Visual Studio Online to host my code. I build and test locally, and when I'm happy, commit to visual studio online, then RDP onto my build machine and then pull, build and deploy from there.
I've actually gone one step further by creating build and deploy powershell scripts so I don't need to run visual studio.
This problem has been addressed in version 2.5.216 of the Service Fabric SDK.
In the publish profile schema, you can now:
Compress the package to speed up transfer
Set the timeout duration to a value greater than 10 minutes
Add the following line to the PublishProfiles\Cloud.xml file to enable compression and change the timeout from 10 minutes to 60 minutes:
<CopyPackageParameters CopyPackageTimeoutSec="3600" CompressPackage="true" />
I followed a similar approach to Andrew Shepherd suggestion. Edited the powershell deployment file located in <MyServiceFabricApp>\Scripts\Deploy-FabricApplication.ps1 and changed the $CopyPackageTimeoutSec variable to 3600. A code snippet is shown below :
Param
(
....
[int]
$CopyPackageTimeoutSec = 3600
)
...
Related
I have a .NET 7.0 blazor wasm app, that I deploy to a windows server running IIS. This has worked fine, until i added the following to my project (The client, and the project is .net core hosted):
<WasmEnableSIMD>true</WasmEnableSIMD>
<RunAOTCompilation>true</RunAOTCompilation>
First i got the following error in my build pipeline:
error NETSDK1147: To install these workloads, run the following command: dotnet workload restore
So i added a command line step to my build pipeline where i run the following command:
dotnet workload restore
So far so good. Now the project builds again. But my release now fails. I have 3 steps in my release pipeline for my IIS server:
Stop app pool
deploy my app
start my app pool
This worked fine before adding the two statements above. But now i get the following error:
Failed to deploy web package to IIS website.
Error: Unrecognized argument 'Files\IIS\Microsoft'. All arguments must begin with "-".
Error count: 1.
Error: The process 'C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe' failed
with exit code 4294967295
I can't seem to find a solution, so has anyone tried something similar?
Apparently i wasn't the only one with the issue:
https://github.com/microsoft/azure-pipelines-tasks/issues/17634
I ended up removing web deploy 4.0, and now it works again.
Maybe if I had waited longer, i wouldn't have to remove web deploy 4.0
When I run simple powershell with only ls command in it through Azure pipeline self-hosted agent I see error:
An error occurred while creating the pipeline.
+ CategoryInfo : NotSpecified: (:) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : RuntimeException
The same script runs fine locally in the same folder on the same machine (when no Azure agent is involved). The pipeline has not been changed in months.
The execution policy is set to "Unrestricted".
There is no difference whether the agent is run with admin permissions.
I checked and the files in the folders of the agent do not look blocked or read-only.
We run tests through powershell scripts and they started to fail last week, without any obvious reason. The only thing that I have installed on the same machine, is Visual Studio 2022 Preview 5, but I have restarted the machine immediately after the installation has passed successfully and the next day the tests have passed.
I had a look through similar errors here, in stackoverflow, but they were not useful, including this one PowerShell "an error occurred while creating the pipeline" #Requires -Version 3.0
Do you have an idea what can cause this?
The PowerShell scripts started passing when I changed the Azure Powershell pipeline task version from 1* to 2* (the latest available for our pipelines).
I do not know why this fixed the issue, as I think the difference between these 2 version is that version 2* can be executed on agents that have operating system that is not Windows.
I have a .NET Core repo in VSTS. I'm trying to create a Build pipeline that builds a Docker image and adds it to my Azure Container Registry. My Build pipeline has a Docker task. This task has the "Build an image" action selected. This action relies on my Dockerfile, which looks like this:
FROM microsoft/dotnet:2.1.2-runtime-nanoserver-1803
# Install .NET Core
ENV DOTNET_VERSION 2.1.2
When my Build pipeline runs, I get an error that says:
failed to register layer: re-exec error: exit status 1: output: ProcessUtilityVMImage \\?\C:\ProgramData\docker\windowsfilter\82aba535faccd8bf0e5ce3c122247672fa671214000a12c5481972212c5e2ca0\UtilityVM: The system cannot find the path specified.
##[error]C:\Program Files\Docker\docker.exe failed with return code: 1
Why am I getting this error? How do I fix it?
It should be the same issue with this one : https://github.com/Microsoft/vsts-tasks/issues/6510
Seems it still have some issues with nanoserver-1803
Just try to setup and host a custom agent on Azure VM, then check it again.
https://github.com/Microsoft/vsts-tasks/issues/6510#issuecomment-370152300
I found maybe an explication about this error: VSTS agents seem not
support nanoserver-1709 actually. Maybe this will change with the next
version 1803.
See details here: Microsoft/vsts-agent#1393
When I setup and host a custom agent on a machine on Azure, it's
working. So it's not a bug with this task. I close this issue. Thanks!
I was learning how to use the Microsoft Azure Tools for Visual Studio to develop an Azure cloud service at :"Getting Started with the Azure Tools for Visual Studio".
I successfully completed the following steps:
1. Install the Azure tools.
2. Create an Azure cloud service.
3rd step was build and debug the cloud service, where i was stuck.
While debugging i got an error "Failed to initialize Microsoft Azure Storage Emulator".
I did try various methods given on various websites to initialize the Storage Emulator, but none of them worked for me.
When I was trying the command WAStorageEmulator.exe init , i got an error "cannot create database".
Any help would be greatly appreciated.
Step 1 : Start your system in safe mode (Immediately after the computer is powered on or restarted tap the F8 key to enter safe mode).
Step 2 : In safe mode go the path C:\Program Files (x86)\Microsoft SDKs\Azure\Storage Emulator.
Step 3 : Search for WAStorageEmulator.exe - config file.
Step 4 : Edit WAStorageEmulator.exe with Notepad++ (any editor).
Step 5 : Change the port numbers as shown in the above snapshot.
(By default the port numbers will be 10000, 10001, 10002).
<services>
<service name="Blob" url="http://127.0.0.1:30000/"/>
<service name="Queue" url="http://127.0.0.1:30001/"/>
<service name="Table" url="http://127.0.0.1:30002/"/>
</services>
Step 6 : Save the file and restart your system in normal mode and run the program.
I hope this helps.
I had a similar problem and it sounds like one of the answers posted here:
This post talks about removing old mdf files so you can install again
This seems to be closer to what you are experiencing.
I hope this helps
Open MS Azure Command Prompt. Type (depending on your local db name):
SqlLocalDb stop projectv12
SqlLocalDb delete projectv12
Then go to
C:\Users(admin)\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances
and I deleted all instance in there. Then try re-install the Azure storage emulator. This worked for me.
A re-boot is not neccesary as per the accepted answer.
Open a Powershell window in admin mode.
Enter the following command: netstat -p tcp -ano | findstr :10000
That will tell you what process id is using the emulator designated port.
Use the Detail Tab in Task Manager detail to find the associated application for the process id. Often times this is something like bittorrent/utorrent.
Kill that process and you're done.
..
But if you absolutely must run the conflicting application while you develop then you can change the ports used by the emulator.
To change the ports used by the emulator, then in powershell:
chdir "C:\Program Files (x86)\Microsoft SDKs\Azure\Storage Emulator"
.\WAStorageEmulator stop
Then edit the config file as per the accepted answer and just save it.
C:\Program Files (x86)\Microsoft SDKs\Azure\Storage Emulator\WAStorageEmulator.exe.config
You don't need to copy it anywhere. Then back into Powershell and :
.\WAStorageEmulator status
.\WAStorageEmulator start
Make sure you have SQL Server Express or SQL LocalDb installed. You should then be able to type
.\AzureStorageEmulator.exe init
Or, in this older case:
.\WAStorageEmulator.exe init
...and it should install the default database. Note I'm using the PowerShell syntax. If using the command prompt, it's minus the .\ portion.
It's not always a port conflict, contrary to what other posts may suggest.
You can download SQL Server Express editions here:
https://www.microsoft.com/en-us/sql-server/sql-server-editions-express
You should see something like this when you run the command:
PS C:\Program Files (x86)\Microsoft SDKs\Azure\Storage Emulator> .\AzureStorageEmulator.exe init
Windows Azure Storage Emulator 5.10.0.0 command line tool
Empty SQL Instance. Autodetecting SQL Instance to use.
Looking for a LocalDB Installation.
Probing SQL Instance: '(localdb)\MSSQLLocalDB'.
Caught exception while probing for SQL endpoint. Login failed for user 'somedomain\someguy'.
Number of SqlErrors Reported: 1
SqlError: System.Data.SqlClient.SqlError: Login failed for user 'somedomain\someguy'.
Could not find a LocalDB Installation.
Probing SQL Instance: 'localhost\SQLExpress'.
Found SQL Instance localhost\SQLExpress.
Creating database AzureStorageEmulatorDb510 on SQL instance 'localhost\SQLExpress'.
Granting database access to user somedomain\someguy.
Database access for user somedomain\someguy was granted.
Initialization successful. The storage emulator is now ready for use.
The storage emulator was successfully initialized and is ready to use.
PS C:\Program Files (x86)\Microsoft SDKs\Azure\Storage Emulator>
The problem is with the “(localdb)\MSSQLLocalDB” SQL Service with Permissions.
The best option is using below commands,
Step 1: Go the path “C:\Program Files (x86)\Microsoft SDKs\Azure\Storage Emulator”
Step 2: Open PowerShell as Administrator,
Step 3: Run the below command in PowerShell,
“AzureStorageEmulator.exe init -server . -sqlinstance SQLEXPRESS -forcecreate”
Below is the output,
Step 4: Run the below command in PowerShell to Start Emulator,
“AzureStorageEmulator.exe start”
Below is the output,
Step 5: After that check the “SQLEXPRESS” Databases,
New Database is created.
Now you can use the Storage Emulator.
We have started migrating our one of several projects to team city as part of CI. Below is how we have setup teamcity build. We are trying to deploy WebSite.
1) Build Step 1 (Package installation)
Using "command line " runner type install required package.
2) Build Step 2 (Build)
Using Runner type "Visual Studio (sln)" (Visual Studio 2010) build website.
3) Build Step 3 (Deploy Web Site)
Using ".Net Process Runner", deployer.exe (x86 built with .Net Framework 4) deploy site.
Deployer.exe reads config file. Config file contains "BuildId", "Environment" and "Servers" where we want build to be pushed.
<buildType id="bt52">
<env name="Debug">
<server path="SERVER1" />
</env>
<env name="QA">
<server path="SERVER2" />
<server path="SERVER3" />
</env>
<env name="UAT">
<server path="SERVER4" />
<server path="SERVER5" />
</env>
</buildType>
Deployer.exe is called with required parameters as below. Which reads config and deploys site to Server2 and Server3.
Deployer.exe "bt52" "QA" "siteQA" "E:\BuildAgent\work\2483052e33e5e1e8\src\diy\" msdeploy.exe
Problem area is step #3.
When we run deployer.exe using .Net process runner as part of team city we see its hanging and not responsind sometime even for 45 minutes. When we try to execute same deployer.exe from build server using command line script executes within couple of seconds.
E:\TeamCity_custom_applications\deployer>Deployer.exe farm1-1 QA siteQA E:\BuildAgent\work\2483052e33e5e1e8\src\diy\ msdeploy.exe
Info
: Processing batch run ... Info : Processing command ...msdeploy.exe
-verb:sync -source:contentPath="E:\BuildAgent\work\2483052e33e5e1e8\src\diy\" -dest:contentPath="siteQA",wmsvc="SERVER2",userName="*****",password="******",authType="Basic"-skip:objectName=filePath,absolutePath=web.config -skip:objectName=dirPath,absolutePath="bin" -enableRule:DoNotDeleteRule -allowUntrusted Info : output >>Total changes: 0 (0 added, 0 deleted, 0 updated, 0 parameters changed, 0
bytes copied) Info : error >>(none) Info : ExitCode >> 0 Info :
Processing command ...msdeploy.exe -verb:sync
-source:contentPath="E:\BuildAgent\work\2483052e33e5e1e8\src\diy\" -dest:contentPath="siteQA",wmsvc="SERVER3",userName="******",password="******",authType="Basic"
-skip:objectName=filePath,absolutePath=web.config -skip:objectName=dirPath,absolutePath="bin" -enableRule:DoNotDeleteRule -allowUntrusted Info : output >>Total changes: 0 (0 added, 0 deleted, 0 updated, 0 parameters ch anged, 0
bytes copied) Info : error >>(none) Info : ExitCode >> 0
Info: Deploy Script Complete.
One more thing we observed is running deployer.exe through teamcity I see that site content gets copied but only for 1 server and teamcity build status stays in "Running" mode. I am wondering if someone can please put little bit of insight on how can I look into this issue.
Update 1:
Thanks for your time looking into it !! What we ended up doing is, Instead of running command "msdeploy.exe" from "cmd.exe" we added "msdeploy.exe" location as Environment variable and executed "msdeploy.exe" in loop for # of servers. This has resolved issue of hanging. Now I am just curious to know why would it behave in such manner where if you execute "msdeploy.exe" from "cmd.exe" it would hang while running directly "msdeploy.exe" it would execute successfully. Any insight into same would be greatly appreciated.
Update 2:
I have added image which explains behavior using process explorer. If we kill msdeploy.exe from process explorer than for next all deployments to that server will not have the issue of build hanging. Please see below image
To be honest, it sounds like you're running into issues with redirecting input/output streams. TeamCity is running your application in a totally headless environment and then you, in turn, are attempting to redirect and parse the output of msdeploy.exe
If that's the case, I'd recommend looking into using the MSDeploy API instead of msdeploy.exe. The latter is just a command line wrapper for the former, so all the functionality is available to you. There's a sample deployment application available on the IIS blog if you need help getting started.
It seems you have NUnit build step configured in TeamCity and invoke cmd.exe from your test. This looks like an issue with the test code then. Most probably it will reproduce without TeamCity if you run the test in question with NUnit directly.
As Richard noted, most probably the issue root cause is related to stdin/stdout processing.
If you want to fix it in your code, you can try to experiment by explicitly closing stdin or the other way around, try writing something into it, etc.
Work around we did is, we observed msdeploy doesn't take more than 3-5 seconds to execute and deploy (Even for our biggest project which is almost 300mb website). So we set timeout of 20 seconds. So far since last 1 weeks we have not seen any issue with it and hopefully it will not cause more trouble but still we are not sure why such behavior.