I have a SSIS package with script task, and is created in VS 2015. I am able to edit script task and opens in VISTA (VstaProjects), set a break point and shows there. But when I close the VstaProjects solution, the breaskpoint disappears in Scripttask in dts package and if I run the task in debug never hits the break point. I am using,
SQL Server Data tool : 14.0.61712.050
SQL Server Integration servcie Designed 14.0.1000.169
Visual Studio Enterprise 2015 v 14.0.25431.01 Update 3
Specifically to the problem of breakpoints not saving in the project: ReSharper might be causing this issue if you have it installed.
For me, disabling "Debugger Integration" in ReSharper options fixed breakpoints not being saved when closing the VSTA project.
When you set the break-point, you must build the solution; save it; close VSTA; then click on OK. Failure to do any of these steps will wipe out the breakpoint.
See my answer here for more details. https://stackoverflow.com/a/49640300/4630376
Related
Created a stock Blazor project (Client or Server side, both do it).
When I open the _Imports.razor, not a problem.
Open NavMenu.razor, a problem.
The IDE opens the file, displays formatted Razor and after a couple of seconds just hangs, CPU usage for devenv.exe goes 50% and stays there until End Task.
Any idea how to fix this? The IDE should not hang when I try and work with a Razor file.
Thanks to the effort by these guys, changing the IDE font from 'Cascadia Mono' to Consolas sorted the problem:
https://youtrack.jetbrains.com/issue/RSRP-487353/Visual-Studio-2022-stops-responding-when-used-with-Resharper
(Note: Not using Resharper, stock VS2022 install)
On Visual Studio 2022, Windows 11.
Linq to SQL tools is installed from installer (Individual Components).
When right clicking a dbml file and View Designer, it just sticks on this and eventually needs an end task:
Tried (to no avail):
Clearing all app.config connection strings in the same project (in case it was silently barfing on one of those)
Installing older .NET frameworks, ticking on Data Storage and Processing and Data sources and service references
Any ideas what might be causing this? (Ran OK under Win 10 / VS 2022).
Edit: I've had this after every new PC install with Win 11, VS 2022 (3 work PCs), but it seems to resolve itself after a few days. I now know why, see marked answer re toolbox.
I experienced the same problem on Win8 with VS 2015 and 2017 and 2019, Win10 with VS 2015 and 2017. I did not solve the problem. Do not know what causes this problem. But now on Win11 with 2022 I opened my problematic DBML file, it took really long time to open (during opening it showed Not responding etc.) but finally VS opened DBML file. Then I made a change in the designer (just moved class a little bit = change = auto-generated file will be re-generated after save) and saved. Now this particular DBML file is opened within a second. Try it.
Viewing the Toolbox and (optionally) resetting it (right click > Reset) seems to solve this. It seems the designer can't open when the toolbox is not initialised (or fails to initialise). It is often a while before I open the toolbox on a new install so I kept on encountering this problem.
I'm creating script tasks in SSIS packages using the free BIMLExpress. Since we have different versions of .NET Framework installed in our environment I really need to be able to set the Framework version for the script project. Although I know how to change it manually, it would be very difficult to change it manually.
I have already tried looking for a solution and this answer suggests to use TargetFrameworkVersion property but I don't see that property at all, I've tried using it with no effect. I don't know if it only works with BimlStudio the paid version.
I'm using BIMLExpress 5.0.61915.0 with Visual Studio 2015.
Any help is greatly appreciated.
Thanks
I opened the generated .dtsx package and found that the TargetFrameworkVersion node placed inside of a separate PropertyGroup node. After I had moved it out to the first PropertyGroup of the same arrayElement node, then reopened my package in Visual Studio again, issue was gone! So you can write a script to move TargetFrameworkVersion node into the proper place for now.
Varigence support team told me that a public preview release is coming late next week which will include a fix for that.
I am using Visual Studio 2008 to build my projects.
I often take existing sample code and edit it and toy around with it, as I am just learning and I'd like to advance my skill.. it's nice to have a template to work with.
That being said, I often get the build error "Post build event failed". This is often accompanied by a "could not find xxx.sbr file" or something. I do not know what an sbr file is, not a "post-build event". Re-building doesn't seem to help, and clearing all the files out before tying another build does not help either.
That being said, the executable still always gets built.
I was wondering:
What is a post build event and what are the implications/causes of its failure?
What is an sbr file? I tried researching this a bit.. a "Source Browse File"? This site seemed pretty informative: http://www.ehow.com/facts_5657521_file-extension-sbr_.html
The problem is, I don't understand why the compiler would complain about not finding this (isn't it supposed to MAKE this?) and what EXACTLY it does ("enables Microsoft Visual Studio to access your source code" - can't it do this anyway?)
Thanks!
R
post build event is just a command you can have visual studio run after it's finished - maybe to kick off tests or build an installer.
It's in properties->build events in the menu - right click on the project.
The SBR file is used by visual studio to browse sources and lookup which function is in which file. I have had problems where somehow it's internal list of dependencies gets screwed up and it always rebuilds one of them.
Try a clean and rebuild, then try quitting visual studio and deleting the .ncb file
SSIS (SQL 2005) packages that have a script task that invoke custom .NET dlls throw the following error when run in a 64 bit environment
The task cannot execute in 64-bit environment because the script is not pre-compiled. Please turn on the option to pre-compile the script in the task editor.
The script tasks are set to PreCompile=false because the referenced dll is generated by the build process.
The suggested workaround is:
Option 1. With precompiled=True, Open, save and close the package in BIDS after the build is complete
. This will recompile the reference and generate the embedded 64 bit binary in the SSIS package and will cause the above mentioned error to go away. However, this also means that someone has to manually open the SSIS packages after the build is complete.
Option 2. Stick to 32 bit mode.
Option 1 is the feasible one of the two, but impractical. With 200 SSIS packages - we are short of hands to finish this task every time we generate the build.
Option 2 is out of the question because 32 bit just doesn't scale for us.
Now the questions:
1. Do you folks have a build process for your SSIS packages? If yes, can you share your practices
2. How do you manage script tasks? Are you comfortable bundling the developer version of the referenced dll in your scripts?
This is probably not what you want to hear,but i would suggest exploring the idea of replacing some of your script tasks with custom components. There are plently of samples on codeplex. This would allow easy updates because you would just drop new component builds and the referenced assemblies into GAC.
HTH
Pragmatic Works has something (I have never used) called BI xPress which has something which might help.