Our build pipeline has been working fine, producing and saving packages to our Azure DevOps artifact feed. Although, we recently started seeing a strange failure in Visual Studio 2019 when trying to upgrade one of the packages to the latest version per to the following screenshot:
As the screenshot depicts, the package version 1.0.1-preview4 does exist but the project is not upgraded to it and version 1.0.1-preview3 has to be picked up instead to upgrade! Any idea what the root cause of this issue is and how to address this problem?
I run into this issue quite frequently and it is caused by Caching. Clearing your Nuget Cache will resolve the issue. See this StackOverflow post:
Package is not found in the following primary source
Apart from cleaning the cache, also check if the version 1.0.1-preview4 is valid(unlisted or deleted?) in your list.
Then use the filter to locate the View of the 1.0.1-preview4 package. Determine the view it belongs to, #Local, #Prerelease or #Release. After that go feed settings=>Views to check the related permissions:
Make sure your local account has the permission to the View the 1.0.1-preview4 package belongs to.
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'm the administrator of a WebApp and I'm having an strange behavior while using continuous delivery. If I right click site project and choose Publish site works fine, but if I use VisualStudio.com Build and Release I have following problem:
As I said, if I publish site everything is ok. I used Kudu to check files after Release and Storage is at bin folder.
Here are some of configs:
And here are Build and Release results:
I would suggest you try adding assembly binding redirects for the Windows Azure StorageClient library.
Reference: http://robertgreiner.com/2012/12/could-not-load-file-or-assembly-microsoft-windows-azure-storage-client/
Also check this https://devnet.kentico.com/questions/windows-azure-storage-dll-version-mismatch link which has similar issue discussed and check if this helps.
Also try the below workaround
UnInstall-Package WindowsAzure.Storage
Install-Package Microsoft.Data.Services.Client -Version 5.6.0
Install-Package WindowsAzure.Storage
After researching a lot I found that WindowsAzure.Storage v9 is not compatible with WebJobs. I just downgrade to V8.1.1 and now is ok.
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'm using Red gate DLM Automation version 2 on VSTS. I installed DLM on the build server, it's fully licensed, and I have noth the build and release VSTS plugins installed. But now, when I perform a build on VSTS, I receive the following error message:
System.Management.Automation.CmdletInvocationException: A parameter cannot be found that matches parameter name 'transactionIsolationLevel'. ---> System.Management.Automation.ParameterBindingException: A parameter cannot be found that matches parameter name 'transactionIsolationLevel'.
My initial guess is that I have a version conflict between some Red Gate PowerShell libraries, but I cannot find any further information on this error.The build server is running PowerShell v4. The SQL code being built does not have any references to "transaction isolation" in it, but I don't think that's the problem. I have completed successful builds on this VSTS server in the past and am now confused what caused this error to start appearing.
Thank you!
You need at least 2.0.3 of the DLMA install on the local agent to work with the VSTS plugin - we added the Transaction Isolation Level option very recently, and VSTS auto-updates, but the DLMA install doesn't.
Sorry about that - we are looking into better update / communication mechanisms to keep these things in sync in future (or at least tell you what the problem is) but aren't quite there yet.
If you're still having trouble after updating the DLMA install on the local agent, please do get in touch via support#red-gate.com and we'll sort it out for you.
Having (presumably) understood the motivation behind Nuget, I want to know, whether we still require internet access to download a package which is already being downloaded earlier for different project in different solution?
I believe you can even set up your own feed stored on the file system as described here.
You can setup your own local NuGet repository as As Denis Ivin has already said.
NuGet also has its own local machine cache which keeps NuGet packages that you have installed previously (C:\Users[UserName]\AppData\Local\NuGet\Cache). You can install these by selecting the Recent packages tab in the Manage Packages dialog.
Having your own local NuGet repository is probably better since the cache could be cleared.