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?
Related
I have just created a hosted blazor webassembly pwa project, which generates client, server and shared projects, all fine. I start the solution and everything runs fine.
But after I start to add small changes to the projects it stops working with a message like this:
"Failed to find a valid digest in the 'integrity' attribute for resource '' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked."
I search the net and stack overflow and find others having almost the same problem. Some can do clean and rebuild to solve this, but that's not working for me.
So, what is this? Why is this happening, totally useless?
Is it the PWA feature? Should I create a new solution without the pwa enabled?
It started happening to me recently. Only on a published released solution. Not on local debug.
Clean+rebuild didn't work for me. I had to delete bin and obj folders from both Client and Server (note: tried client only and, it did not work but, did not try server only) then republish.
cf. Failed to find a valid digest in the 'integrity' attribute for resource in Blazor app
It now occurs each time I upgrade or downgrade a package.
I've done several tests and can confirm :
DLL are the right ones (SHA256 hash validated) on the server.
the string in the blazor.publish.boot.json is the right ones.
I was even able to get rid of the problem by reverting to the previous package version prior to the bug (which changes back the related entry in blazor.publish.boot.json). Which for me confirms a reference is not updated somewhere.
The only significant changes I've made recently are switching to VS2022 and .NET6. The bug appeared after I did my first successful publish on Azure through VS2022: 1st package upgrade after that triggered the bug.
I tried to find the solution of my problem on google, many blogs and tried many suggestion but nothing is working.
My problem is like this:
TeamCity Solution Build is creating artifact and publishing it but the package version is not showing in visual studio package Manager Console and not even in Octopus Library External Feed test. Because of this all my builds are failing as octopus is not able to find the latest package which is being generated in the current build.
I dont remember making any change in setting or configuration of teamcity or octopus and this issue came up suddenly. Before this everything was working fine.
Can someone please help me in solving this issue as I'm stuck here?
I have already found an alternative which can be to push packages to Octopus repository and use the package from there but I dont want to change the configurations now and trying to fix this issue first.
I have a VSO release management definition in which I'm deploying a cloud service and then running some tests. The deployment executes without issues, but then the tests don't run, I recieve the following message in the logs:
Warning: No test is available in My DLL Path. Make sure that installed test discoverers & executors, platform & framework version settings are appropriate and try again.
Now, the strange thing is that this release is triggered by a build, which runs exactly the same set of tests and they all run happily.
I've included a runsettings file specifying the framework version (based on some SO posts I found from a year ago with a similar issue) but its made no difference. Been messing with this for nearly 2 days now with no progress. Any suggestions happily accepted!
Arrrrgh! So it turns out, if I deleted the whole project, created it again and added my tests again, it just works. Gremlins apparently!
Admins, if this needs to be deleted, go ahead
I have a PHP Azure project which I have to manage with Powershell cmdlets. One of these, Publish-AzureServiceProject doesn't seem to be detecting file changes so these are not updated on the cloud (even though no errors are displayed).
I have remote desktop'd into the machines and the code is definitely not updated from weeks ago.
If I deploy to the local emulator, it is fine but this is much more obvious because it displays "removing old package" and "creating local package". The cloud package definitely contains the latest files, so the packaging is working fine.
Can anyone tell me how to force the publish to update the files on the cloud and more importantly, why this is not happening? Also, if I force the update, will it deploy to a new box and get a new IP Address?
Thanks.
It seems to work now.
I have removed and reinstalled azure libraries from my machine and created a new project from scratch and copied the original files over into it. I have not included diagnostics (not sure if that's an issue) and I have modified the Publish-AzureServiceProject script to select the subscription each time before it publishes.
It is possible that the subscription confusion was not helping (I have two Azure subscriptions and it might have used the wrong one at some point and done something weird) and also it was possible there was some conflict with various versions of the Azure SDK since I have been using it for over 6 months but at the moment, all is good.
A related article on my blog here: Problems with PHP Azure
Thanks for the interest
I was looking for some insight about what happens to existing workspaces and files that are already checked-out on people, after an upgrade to TFS2010. Surprisingly enough I can not find any satisfactory information on this. (I am talking about upgrading on new hardware by the way. Fresh TFS instance, upgraded databases)
I've checked TFS Installation guide, I searched through the web, all I could find is upgrade scenarios for the server side. Nobody even mentions what happens to source control clients.
I've created a virtual machine to test the upgrade process, The upgrade was successful and all my files and workspaces exist in the new server too. The problem is: The new TFS installation has a new instanceID. When I redirected on the clients to the new server, the client seemed unable to match files and file states in the workspace with the ones on the new server. This makes me wonder if it will be possible to keep working after the production upgrade.
As I mentioned above I can not find anything on this, it would be great if anyone could point me to some paper or blog post about this.
Thanks in advance...
When you do an upgrade your server ID should stay the same. You may need to chnage it is you want to clone your enviroment.
In your test senario you are creating a clone of the TFS server rather than a strate upgrade.
ChangeServerID
You are probably running into problems as this has been run on your test envionment to facilitate it runing on the same network as your production TFS server.
All workspaces and shelvesets remain unchanged, and people will be able to continue working immediately. Even checked-out files are OK and will be picked up correctly.
I would recommend upgrading the server first, and keep the clients as 2008 (using the Forward Compatibility Pack), and then upgrading the clients to 2010 as and when the projects are upgraded.