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
Related
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?
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.
After I've excluded a package from a project by choosing Project->Exclude From Project, how do I 're-include' it later?
I thought it was Project->Add Existing Package, but that adds a copy of the package.
It's very easy ,
if it's old version of Visual Studio like 2012 ,
just Right Click on the folder > Add > Existing Item > choose the file which has been excluded
if it's old version of Visual Studio like 2008 ,
Right Click on the folder > Add > Include in Project
According to the documentation, SSIS will copy your existing package and place the new copy into your project's folder location. However, if your package is already in this location, it is supposed to just open the package. Since you excluded the package, including it again should work fine without it making a copy of it. The thing I notice, however, is that you don't mention getting an error. Normally you would get an error if you were making a copy and it was being placed in the same location as the original. Most like either you are renaming the package during the "Add Existing Package" stage, or your package isn't in the correct location.
If your package is getting copied with a new name, I have found some indication that this might be a bug. The work-around seems to be to then delete the original and rename the new copy. It isn't pretty but it seems to be your best option.
The answer is that you cant just "include" a package. Its more of an import which makes a copy... if the package already exists it adds a (1) to the name of the package.
This is the functionality for SQL Server Business Intelligence Development Studio that comes with SQL server 2008 R2. Doesn't make much sense but Im sure they fixed that in future BIDS releases
In Visual Studio 2015, I have found that I can re-include packages by right-clicking on the project and choosing Add | Existing Item... (not Existing Package).
It makes no sense, but it works. I guess it will work the same in other versions of VS.
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).
------ Clean started: Project: DataService, Configuration: Debug Any CPU ------
O/R Designer validation failed for file: a.dbml
O/R Designer validation failed for file: b.dbml
O/R Designer validation failed for file: c.dbml
O/R Designer validation failed for file: d.dbml
O/R Designer validation failed for file: e.dbml
O/R Designer validation failed for file: f.dbml
Error: The operation could not be completed. Unspecified error
This error is intermittent. Sometimes the clean is fine, sometimes this happens.
I'm running VS2008 version 9.0.30729.1 SP - 64bit.
Is there some way I can disable the O/R designer's validation or otherwise stop this from occuring?
I had to close Visual Studio and reopen it. Solved this for me. In another case I had to roll back my DBML file, then close Visual Studio, and reopen it.
Looks like a bug for Microsoft to fix.
I had also the same problem, but the following procedure let VS always compile the code correctly:
Close VS
delete all files in the obj\x86 (and eventually x64)\Debug (and Release)\ directory
Then start VS again via command line using
<Path>\devenv.exe /ResetSkipPkgs (optionally: <Name>.sln to open directly the correct project)
(Not sure whether the /ResetSkipPkgs is necessary, but another article told so. I made a small batch script which does all of this automatically).
The code should compile now without any problems!
For reference, my script file looks like this:
del /Q C:\[...]\[...]\obj\x86\Debug\*.*
"C:\Programme (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe" /ResetSkipPkgs C:\[...]\[...]\<Name>.sln
(I always develop in debug mode, thus I only delete the matching x86\Debug directory...)
This problem appeared after I copied a property in a table. For some reason the copied property had the same storage name. Deleting this storage attribute in dbml xml for those copied properties solved the issue.
So the source of this problem is most likely some error in the dbml file. If you have version control, check what you changed and maybe you'll spot the error.
vs2010 was giving me this error while vs2017 was building it fine,
running vs2010 with /ResetSkipPkgs (Andre's answer) solved for me.
I solved moving a table around in the .dbml designer (so basically not changing anything), saving and rebuilding the project.
VS2017 was giving this error for one of my DBML files, and was preventing me from successfully building the project. None of these answers worked for me. Things I tried were:
(1. Check csproj file for any inconsistencies such as missing item groups or appended numbers on filenames
2. Running devenv.exe /ResetSkipPkgs
3. Deleting visual studio temporary files)
This error was driving me crazy as the error visual studio shows is very cryptic. My eventual solution was to open the problematic DBML in design mode, and delete every stored procedure (I left the tables). Ran a build and the error stopped generating. Then I simply re added all the stored procedures back to the DBML, and that seemed to have done the trick.
So far, deleting and re-adding the dbml file is the only thing that has worked for me.