When I edit a script component on SSIS, it takes upwards of 30 seconds for a new instance of visual studio to open so I can edit it.
This makes debugging and making small changes very time consuming. I will be using SSIS packages a lot going forward, and I was looking for a way to speed up this process.
The closest solution to my problem was found here:
ssis vsta script component slow to open on edit VS2015
But this didn't seem to resolve my issue after reinstalling SSIS as a new instance.
Has there been a fix for this in VS 2017?
Related
Using the SSIS Data Tools extension for Visual Studio, it is possible to carry out various operations in a straightforward manner. However VSTA and the Script Task are a major exception—specifically in VS 2019.
After editing an existing Script Task the script text will reset to the default value.
Creating a new Script Task (other than the default) is likewise impossible, as far as I can tell.
I have tried editing the base64 string in which the VSTA task is stored within my .dtsx files.
After that I tried manipulating the files and directory structure under the VSTA temp directory in order to persist changes in the scripting solutions/projects. I have also tried many other tactics, such as including the task implementation as an additional source file, as a binary reference, or via partial classes, a base class etc., within the Script Task.
But none of these approaches (even if they were to work) are necessarily maintainable or simple in the context of a team.
Is there any sustainable long-term alternative that allows Script Task development in VS 2019?
The SQL Server Integration Services Projects extension for Visual Studio 2019 has a fix.
Script Task creation and editing appears to be working as of version 3.2.1 of the extension.
This was apparently released some time in the past few weeks (as of date of writing, 26 November 2019).
I have an existing SQL Server 2012 SSIS solution, deployed and pulling data from an external (Oracle) server each day. I need to copy all connections / variables / packages from that solution and put it in a new solution I'm writing.
Once I copy it to the new solution, I will rename each package and adjust the queries in the data flow source pull object; then save, build, deploy as a whole new solution. The old one will not change or go away. I'm just trying to use the project/solution itself as a template, pulling variable/logging/metadata that's not as easily by opening a package.
Is this doable? I don't see many answers doing a quick Google search. Forgive me if this is a duplicate question, unclear or easier than it appears.
In Visual Studio click on your project and select the "Add existing package" from the context menu. This makes a copy of the dtsx file, and leaves the original intact. Then you can make edits to your new copy.
I have a fresh installation of Visual Studio 2015 Pro Update 2 + SSDT (June 2016).
When I attempt to edit C# code of my SSSIS script component (clicking on Edit Script...), VSTA does open without any warning/error but does not display anything (like if VSTA was called without specifying a solution to open).
However I can see the temporary solution is properly created in the background in a subfolder of folder:
C:\Users\XXX\AppData\Local\Temp\Vsta\SSIS_SC130...
I can even manually open the solution directly from this folder without any problem.
Any idea why the solution does not automatically open in VSTA ?
This occurred to me twice while working in the same environment as you and I hope the outcome for you is different.
The first time:
As for me it was that VS had corrupted the Script Component and too bad so sad I couldn't restore it.
The Second Time:
Moving the project from machine to machine, at some point there was a change to the .Net assembly of the project. Setting that back to 4.5 allowed me to view my scripts again.
Good luck and enjoy the little surprises VS and SSIS combo like to throw at you
VS2008 / TFS Build 3.5 / Ent Lib 4.1
I have a rather large solution that contains several apps. They are all currently using Enterprise Library (v.4.1) for their data access layer.
I added and locally tested a new data access layer that uses LINQ to SQL- it was fast and easy to add and the test went fine. But...
When I checked in the project, it would not complete the build - I get a "Partially Succeeded". There are some warnings, but those exact same warnings were there prior to the build failing.
I took the data access class back out (along with the code that calls it) and rebuilt and it builds fine.
I then added an empty new class and put a single variable in it and referenced it from the code. That built. I then created a new LINQ to SQL class in that new project and did not even reference it. When I checked that in, the build failed again with the "Partially Succeeded" message. No extra errors or warnings.
I love LINQ to SQL, I have used it in a few projects outside of this system, but I now have many hours into attempting to get this to build with no success.
Are all the same tools/libraries installed on the build server as on your desktop - Perhaps the server doesn't have the same vs or .net service pack level? Try running the build "manually" on the build server - load up the solution in Visual Studio on the server and execute the build within the IDE rather than under the TFS build system - this may report problems that you don't see so easily in the automated build.
Check the build log. Visual Studio often reports errors in the output pane text or build-server log text that are not picked up by the GUI error windows. So you will think a build succeeded but an output file has "quietly" not been generated. TFS build logs are usually huge so they are a pain to work through, so start by searching for keywords like "error" or the name of the project that fails rather than trying to read through line by line.
OK, we found it. The issue is on stack overflow elsewhere at
Visual Studio Setup and Deployment build fails with no errors
The issue is a bug in MS setup and deploy that breaks when it hits a line in the project that uses Linq. You have to comment out a line in the project to get it to work. Amazing, ridiculous, and no surprise.
Thanks for the input, it was that input that helped us get to the eventual answer (already on StackOverflow, but didn't have Linq in the title).
I was developing a SSIS project, but accidentaly, I erased it. However I keep a copy of the SSIS package. So my question is, it is posible recover the project using the package? or is someway to read the package content to start over the project?
Thanks
I don't remember there being anything too essential stored in the project files for SSIS projects - you can create a new project and then 'Add Existing Item...' and add the package(s).
#Will gave you the correct solution. Project files are XML files that list which packages are part of a project. You can add an existing package back without any issues. You can even manually add a node if you want by editing the file directly. I use to find this useful before BIDS Helper offered sorting capabilities.
You may also want to implement a version control system if you are working with SSIS. Every once in a blue moon a package gets into a funky, unrecoverable state and we have to rollback to a previous version to get it working again. This happens about 4 times a year for a team of 6 people who work on 100-200 packages. Also, you will never lose a package again even if you erase it on the server and your local copy is wiped out.