Upgraded VS2019 to version 16.11.49 but I cannot access my original SSIS package
-
Hi
I upgraded to new version of VS2019 to 16.11.49. My original SSIS package is not accessible anymore. When I open my original package I get message "This tool window can only be used by a SQL Server Integration Services package document". I am able to create new SSIS package so that tells me that the components are still there. Not sure why I cannot open my original package. What can I do to troubleshoot this issue?
Thank you
-
you need to install the integration services component for you VS version.
for 2019 is on https://marketplace.visualstudio.com/items?itemName=SSIS.SqlServerIntegrationServicesProjects
-
I downloaded and installed it. Still not working.
What else do you suggest I try?
-
Possibly a dumb question, but what version of SSIS was your package targeting?
This is in the SQL Server 2019 section of the forum, so I suspect it is SQL Server 2019, but never hurts to confirm. VS2019's SSIS only works with SSIS 2012 through 2022. If your SSIS package is targeting an instance outside that window (2008R2 or 2025 for example), it won't be able to handle it.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system. -
there is no such thing as a dumb question.
it is sql server 2019:
-
Glad that wasn't a dumb question. I know with SSMS I've hit snags when my SSMS version doesn't match the SSIS version and it will happily push the dtsx to my SSIS catalog, but it pushes it in at the wrong version and breaks things. Was hoping that you were not trying to work on an old (SSIS 2008 R2 for example) dtsx in VS2019.
Next, possibly dumb question, you are opening the .sln file, not the dtsx/dtproj file, correct? Not trying to question your ability to use VS or your knowledge of it and such, but I've done silly things like tried to open the dtsx file directly in visual studio and had it and me get confused as that was the wrong way to open it. More happens with me with csproj files than dtsx/dtproj files, but I learned from my mistakes.
If you are opening the sln file and getting that error, what happens if you make a new empty solution and add the dtsx or dtproj file into your solution? Not ideal, but it could be your solution file is corrupt according to the latest version of VS2019.
Another thought - have you been upgrading this SSIS package from previous SSIS versions? What I mean is did the package start as a SSIS 2008 (for example) and you upgraded it to 2012 then to 2014 then to 2016 then to 2019? The reason I ask is that upgrading USUALLY works, but sometimes can cause issues and it MAY be a bug in the dtsx was ignored until the most recent VS2019 release. If this is the case, you may need to re-create the DTSX file in order to fix the bug. I've hit this with SSIS, but it was ages back when we were migrating all of our SSIS packages from per-instance SSIS packages (ranging from SQL Server 2008 R2 to SQL Server 2012... it was quite a few years back) to a single instance SSIS 2012 server. We did this because we kept hitting deploy bugs when we would push things out to the SSIS server using the wrong SSMS version and it was driving developers nuts. Having 1 SSIS server handling everything means that the devs can all run the same VS version and SSMS version and not have to think twice before they deploy. BUT we hit some snags upgrading the 2008 R2 SSIS packages so we had to rebuild a few of them. Nice thing about rebuilding is we made them much more simple. A LOT were overly complex and we were able to simplify while retaining functionality.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system. -
thanks for the reply.
no such thing as dumb/silly question! 🙂
I haven't done anything different. VS2019 keeps track of which package was opened and I have always been picking the one that appears in the list. It is a .sln file.
I have always been using VS2019 and SS2019 since I started my side project.
Here is the strange part...
I have been keeping backup copies of my SSIS package each time I make changes. I will copy the entire folder storing the SSIS project and add "v1" to it, then "v2" etc to keep track of versions. Out of curiosity, I tried opening an older version and to my complete surprise it opened. I was able to access my SSIS package. It is an older version so I have to still modify it so it matches the latest version (the one that doesn't open). It is very odd that the old version opened up with no issues but the latest version won't open. I have no clue what is going on here. So for now, I have been spending time on the old version and fixing it up so it matches the current version.
It would be super helpful to get the latest version working so it saves me time from re-doing work that is lost.
Lesson learned...be careful when doing upgrades.
-
That is very strange... If you have a diff tool (such as winmerge), it may help you look at the DTSX and/or DTPROJ files and try to figure out what's wrong with them. My guess is that the dtsx or the dtproj file is corrupted somehow and SOMETIMES using a diff tool to compare a working version and a broken version gives you a good idea of how to fix it. BUT always make sure you have a backup (source control, folder backup, VSS, something) before you make changes to the file manually. It isn't working now, but you don't want to make it worse. I often even make a backup of the working copy just in case I do something silly like modify the working file instead of the broken file (which I've done before...).
DTSX and DTPROJ files are just plain text files, so you can open them in notepad to review them, but manually eyeballing a working vs non working file is an easy way to hurt your eyes.
As for version control, you may want to look at setting up a version control system like git. You can self host for free or use a cloud solution but it saves you from having to manually keep track of versions and changes. Nice thing too with git is you can do multiple commits (versions) and roll back to any previous commit (version). When I'm working on things, any time I complete a minor fix or improvement, it gets a commit. If it fixes the bug or the changes mean I want to do a new release, then that branch gets sent for code review (if it is a team project) and merged into the main branch. Then a new branch for the new changes. A few big pros to this approach vs the "V1" "V2" approach is:
1- comments - you can see what each commit changed so you know exactly what each version is for
2- history - if you have 100 commits, you can quickly and easily view all of them (tools like SourceTree make this easy, but if you are a command line person, git can show you the history from there too. SourceTree is just a fancy GUI on top of the git command line.)
3- branches - you can work on multiple independent features at the same time without fear of breaking anything. I say independent because if you modify the same file in 2 different branches you are likely to get a merge conflict
4- Disaster recovery - if you host your git server on a different machine (cloud for example), you have disaster recovery in the event your computer dies or accidental version deletion
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system. -
Thank you for your reply. I appreciate it.
I ended up re-doing the work and it is working now. No clue what happened to the original version but it is ok. Lesson learned...don't update blindly.
Thanks again for your time.
Viewing 9 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply