I used to be able to do upgrade, and it suddenly wont work, not to cloud and not locally.
And there is no error message, so I have no clue what to do.
Publishing a new application works fine.
There seems to be something corrupt with the solution, but I have no idea where I should be looking for this.
In a brand new project, publishing and upgrading a stateful service from template, works without problem.
Things I have done:
Cleaned solution.
Rebuilt solution.
Deleted Debug folders in bin and obj folders.
Restarted Visual Studio.
Cleared MEF Component Cache.
Restarted machine.
Restarted cluster.
The brand new project is deployed to same cluster and upgrade it is working, so I have not deleted the cluster to deploy a new one.
There is no error being thrown so enclosing the script in a try catch seems pointless.
What else can I do here, what can I do to try find out what is going wrong, any suggestions?
I found out it might be a bug. It is reported here:
https://github.com/Azure/service-fabric-issues/issues/240
Summary: When deployed with compression, further upgrades require config version bump, even though config has not changed.
Related
The problem
So I am running into an interesting issue. I have been tasked to change a query for a simple SSIS package in Visual Studio 2015, which is a thing I have done multiple times in the last 6 months.
After changing the package and deploying it (to an installation of SQL server 2016, without errors!) I noticed that the execution of the package (scheduled with SSMS) generates the same result as the pre-updated package, meaning the demanded changes hadn't taken effect. Of course, as test, I have executed the package directly from VS2015 and got the result I wanted.
Ever since I have been running tests and trying to find a solution. The problems seems to lie with the receiving side of the deployment proces.
What I have tried
Deleted the package from the existing project in SSMS and redeployed. Deployment again seemd to succeed but the package didn't show up, so I had to restore an old version of the project.
Deploy the package from multiple different computers with access to VS2015 and the source code. No change...
Deploy the package to a new (empty) SSMS project: package does not appear in the project. This leads me to believe that the old package is kept when I publish the new version to the existing project in SSMS.
Regenating/rebuilding the package in VS2015, frankly this was never necessary and probably doesn't do anything for an SSIS package, but it may help you get an idea of my skill level.
In the past we have had issues with the encryption level blocking the deployment of packages. I have verified these settings and found no issues.
I have verified if any updates have recently been installed to the database server, which does not seem to be the case.
I have (of course) tried to google the issue, which is tricky due to the lack of errors. I have found the following links, that describe the same/a similar issue, but their solutions haven't helped:
https://dba.stackexchange.com/questions/259672/ssis-package-not-being-deployed
Deployed SSIS Package not reflecting changes made to package
What is still left to try
Rebuild project from scratch to see if that version is deployable.
Unfortunately I don't have a lot of experience with this subject and no colleagues or contacts to ask for help.
Thanks in advance.
My workaround
After quite a bit of time attempting to solve the issue I have resorted to working around the problem, by manually importing the .ispac file into the database. While this is not the prettiest of solutions, at least it's a workable one. If anyone has any other idea's I'll gladly see them, but for now the issue isn't nearly as pressing as it was.
From your post. "Deleted the package from the existing project in SSMS and redeployed. Deployment again seemd to succeed but the package didn't show up".
Are you 100% sure you are deploying it to the same project on the same server on the database? Are you refreshing after you deploy?
I have been working with SF for a while now. Recently, I began having a problem when I do a Start to debug. The service shows in error and I get the infamous Partition is below target replica or instance count.. The strange thing is that I can deploy to local or remote SF provision and attach debug with no problem
I thought that something was wrong with my code, but it turns out that when I create a brand new test project, without any custom code, the same thing happens.
Note, this does not happen if I create a .net core service, only the ole .net service..
This is very strange, and I speculate that it possibly caused by the environment or VS.
I am running the latest updates on VS2017, latest SF on Windwoes 10 with latest updates..
PS: I also get the a 64-bit debugging operation is taking longer than expected when I exit the debugger
After upgrade to sdk 2.5.216 and runtime 5.5.216 Test-ServiceFabricApplicationPackage command works only for complete package. In case of partial app upgrade (some Pkg are removed) it results in "Windows PowerShell has stopped working". I have tested on several computers and several apps. to reproduce:
create test app with 2 services and deploy.
change app version and particular service version.
create package and remove Pkg folder from it for the service without modifications.
connect to Service Fabric and test like Test-ServiceFabricApplicationPackage -ApplicationPackagePath "..path" -ImageStoreConnectionString "fabric:ImageStore"
Maybe somebody was able to overcome this issue? or at least has similar behavior so I'm not alone in Universe.
Thanks!
Alex
Take a look at https://github.com/Azure/service-fabric-issues/issues/259
This is a bug in our code. It happens when a compressed package was uploaded and provisioned in the cluster. Testing a new version of the application fails because settings file was not found in the provisioned version.
We fixed the issue and it will become available in one of our next releases.
Meanwhile, you can skip compression or test the version 2 application package without passing in the image store connection string.
Apologies for the inconvenience!
I have tried to upgrade to the ne version of the Service Fabric preview code - 1.4.87-preview - and everything seems to have gone ok, but when I try to deploy a service I get an exception on run telling me that it cannot find FabricRuntime.dll. This goes both for my upgraded project, for newly created test projects and for all samples.
I can see that the DLL is present on the machine and that a system PATH has been set to the directory containing it.
There seems to be nothing wrong with my applications per se, as they deploy fine to a Party Cluster.
Anybody have any idea what is going on. Everything worked fine when I ran the old Service Fabric install. I have tried uninstalling service fabric and installing again, but it didn't help.
The answer is now posted on MSDN forums at https://social.msdn.microsoft.com/Forums/azure/en-US/6c8cc261-6c84-4097-be03-e8073cbc9397/unable-to-load-dll-fabricruntimedll?forum=AzureServiceFabric&prof=required
Copy of answer from MSDN Forum:
This is happening because FabricRuntime.dll is looking for zip.dll that ships with Service Fabric runtime. However since JRE is ahead in the PATH list and it also ships with a zip.dll, FabricRuntime tries to load zip.dll from the JRE folder and fails. We have fixed this issue by renaming our DLLs. The fix will be available in the next update of the SDK. In the meanwhile, you can fix this by adding "C:\Program Files\Microsoft Service Fabric\bin\Fabric\Fabric.Code" as the first entry in the system path and then restarting the machine.
This is the SDK issue, I've opened a GitHub issue at here
I have to Work with WorkerRole project to deploy some services to perform the data sync with the other databses. i tried to publish but stuck, Internalization, Starting, Preparing, Recovering and finally aborted.
After getting the above stituation i build a simple workerrole project and tried to upload the result is same.
And i am not able to find out the problem with the same.
Please provide some help.
A typical problem, when deploying, is having a connection string pointing to the local emulated storage. This is the first thing I'd check if the worker role code runs locally in the emulator but fails when being published to Windows Azure.