I'm trying to develop my first custom SSIS task. I've got two instances of SSDT open -- one for building and debugging the task, and the other that uses the custom task. Then in the first instance, I use the Attach to Process function from the Debug menu to debug the code. That all works fine but my trouble is that each time I rebuild the task and register it in the GAC from the first instance, I have to close and reopen the second instance of SSDT. If I don't, the second instance seems to still use the previous build of my custom task. Is there some way besides closing/reopening Data Tools that will cause it to recognize the new build of the custom task? All the closing/reopening is getting exhausting.
While it has been a decade since I last built any custom components for SSIS, the work cycle is as you describe it.
The best bit of of advice I'd offer is to add post-build steps to your development process to GAC the DLL. Oh, and modify your Visual Studio shortcut to include /nosplash to eliminate the startup splash screen.
Related
I'm still rather new to the world of API programming in Solidworks PDM, and i have run into a cumbersome problem i was hoping to get some insight in: For many normal API's in PDM, it is simply enough to add the .DLL file in PDM-Administration as 'Debug', and from thereon out, whenever the solution in VisualStudio is being rebuild, the PDM-Administration will automatically grab the same DLL-file, the next time it is being called from PDM. This is great for Debugging, no problem here.
But, as soon as the API has to trigger a task (to be executed on a client PC), it can only be added to PDM as a normal task (no debug mode), then added to the 'Task Host Configuration' on the client, and then configured as a 'New Task' in PDM-Administration.
This all works fine; BUT, it takes quite some time to change anything, since the only way i can get changes to take effect, is first to rebuild the Solution in VisualStudio, then manually overwrite the DLL-file in PDM-Administration, and finally reboot the client-PC (to force-update which version of the add-in it sees).
I have tried; logging out/in-again(in PDM), restarting the explorer, and clearing the local PDM-Cache... nothing has happened here
Can any of you give me some advice on how you debug PDM API's?
or at least force-reload a addin on the clients.
Specifically suggestions to task-add'ins will be much appreciated. Thank You.
Unfortunately there isn't a clean way to debug task addins.
It is possible to attach your debugger to the PDM process itself but its not trivial. Here's the gist of it as explained by Lee Young,
It depends on what portion of the task you're attempting to debug. If
you're looking to debug the task setup in the Administration Tool, all
you need to do is attach to the conisioadmin.exe process.
To debug an executing task, it gets a little trickier. Load up your
add-in as usual and select your machine to be the only machine that
will execute the task. (In the task setup.) Close the administration
tool. You'll need to create a symlink from the file in the plugins
directory to your debug dll. I personally use DirLinker. The plugins
directory is located at AppData\Local\SolidWorks\SolidWorks Enterprise
PDM\Plugins\VaultName.
In your sourcecode, place a messagebox.show in the OnCmd method and
place a breakpoint at that line. Once the task loads up, the task will
wait for the messagebox to be closed. When the messagebox is shown,
you can attach to TaskExecutor.exe and then you'll be able to debug.
If you're not hitting breakpoints, make sure you have the correct .NET
framework version selected when debugging.
If you're still not hitting breakpoints, EPDM probably loaded another
instance of your dll into the plugins directory.
For simple task addins, my approach is to debug via the method you described (reload it manually every time). Proper logging will help a lot here (Print ex.StackTrace on every exception).
For more complex tasks, you can create a separate 'debug' project that has some hardcoded (or dynamic) inputs and calls your code. This will get you close before testing in the PDM environment. A PDM task is basically a COM process on the client machine so that's pretty simple to mimic, aside from the actual PDM Task environment, which is full of bugs.
Hope this helps.
I would like to debug a same C# console project from two different instances of Visual Studio to increase my productivity, as the edit-and-continue mode is not always enough, to say the least.
I have no problem opening the solution twice, and debugging different projects concurrently, but when I try debugging the same project twice, it expectedly fails as it cannot replace the executables in the bin folders.
The possibility to debug twice from the same instance of the IDE as explained here is very welcome, but not good enough for me as I want to be able to completely edit my code when needed.
Is there any simple way to achieve this? Thanks!
Instead of clicking Debug or hitting F5, open a command prompt and start the number of instances you want from there. Now start as few or as many Visual Studio instances you want and go to the debug -> Attach... window.
In the Attach to process window, find the instance youw ant to debug and choose attach. This will allow you to attach to as many instances of your applciation as you'd want.
Now, if you want to be able to edit these application son the fly and spin up new instances, that isn't possible because, as you've found out, the executable will eb in use. Short of creating multuiple copies of your output directory and always starting a copy, never the original, you have no way to achieve that.
Just as a note for whoever stumbles upon this page, as it's ranked very high on Google:
If you want to debug two instances of the same program in Visual Studio, this is as simple as opening up two instances of visual studio and pressing f5 in each instance. This works remarkably well, although you want to wait until one program is up and running before you start the second - otherwise you may get conflicts in your bin folder (which is what it seems OP didn't do.)
I would like to simultaneously start multiple instances of a project using Visual Studio. By pressing F5 (Debug -> Start Debugging), at most 1 instance of each project in the solution starts, respectively. I didn't find a way to configure startup of multiple instances of the same project.
The project in question is a console app that is difficult to convert in a way to enable multiple instances within the project.
Well, if you are looking for simultaneously, I don't know.
But you can try right Click on the Project Debug -> Start new instance as many times as you like.
If you don't need to debug you can start multiples instances ("Start Without Debugging")
In case you want to debug an instance you could then attach the debugger to it.
If attaching the debugger is not an option you could use System.Diagnostics.Debugger.Break() method in your code. The equivalent but programmatically.
It's not possible to debug multiple instances of a project using a single project. The IDE/debugger need to synchronize program execution with source code and debugging symbols; it can't do that unless there's only one instance.
You could, however, copy your project multiple times and start them as you describe (as a solution).
Select and Right click any project. Then debug and Start New Instance
I have a VS solution containing several projects. While debugging a particular project all the source files are locked by VS. I would like to unlock sources that the debugee doesn't have dependency on. Is there any way to do this within one solution?
UPDATE:
I'm using Win XP SP3 32bit. Visual Studio 2010, C#. Edit and Continue is enabled. The solution contains 6 projects (number in not important actually), 5 of them depend on the data access layer project which uses Entity Framework. None of the 5 have any mutual dependencies. They are WinForms and Console applications. I would like to be able to run one of the projects and make changes to others without stopping the first. The problem is starting and stopping the project take considerable amount of time.
The Edit and Continue feature is preventing you from editing files if the debugger hasn't stopped the program. The simple workaround is Debug + Break All, you should then be able to edit the files, your changes will be immediately effective provided your changes do not violate the restrictions imposed by E+C. This is the most efficient work flow.
The heavy-handed approach is to disable Edit and Continue. Tools + Options, Debugger, Edit and Continue, uncheck the Enable check box.
I don't think that there is a way to avoid that. While debugging Visual Studio lock all files to prevent any change on them, including those on other projects.
You can try to open the project which you are interested on with another Visual Studio instance to make changes to your files or open files singularly with another editor.
This doesn't quite answer the OP's question per se, but for anyone who has stumbled upon this page in the same (very frustrated) boat as I am, this might help.
The solution: start without debugging.
It was driving me absolutely crazy that Visual Studio would not let me edit files while the app was running. My typical workflow is:
Make some changes
Run the app to see the effects of those changes
Based on the results, make more changes, etc. etc.
The problem is Visual Studio was preventing me from step 3. It demands that you STOP running the app before you can even make any changes (including to a XAML file or adding a file to the project), which also means that you can't go back to the app to double-check something while you are actually programming it at the same time (which is how I work, bro).
Thank god I finally discovered if I run without debugging it doesn't impose this ridiculous limitation. It's still a pain in the butt if you actually need to debug something you have to re-run the app in debug mode, but it sure beats having to kill the app before it will even let you edit a file.
I have a solution with several projects, where the startup project has a post-build event that does all the copying of "plugin" projects and other organizing tasks. After upgrading the solution from VS 2005 to VS 2008, it appears as though the post-build event only fires if I modify the startup project, which means my updated plugins don't get plugged in to the current debugging session. This makes sense, but it seems like a change in behavior. Is anyone else noticing a change in behavior with regard to which projects get built?
Does anyone know of a workaround that I can use to force the startup project to rebuild whenever I hit F5? Perhaps I configured VS 2005 to work this way so long ago that I've forgotten all about it ...
I think you need to reorganize the responsibilities. Each component should be responsible for itself and therefore copy its generated goodness where it needs to go. That way it doesn't matter if/who/what/when/where got built. Whatever is updated will put itself into the proper place.
IMO the other suggestions are no-nos since they'll circumvent the compiler's smarts to know when a rebuild is necessary for the main project. And hence killing any compile time-savings. If your "plugin" projects are assemblies (and not just project-references from the main project), then you do not need to rebuild the main project each time a plugin is rebuilt. The new assembly will get selected into the process / debugger w/o the main project needing a rebuild.
Why not just add a dependency to the "startup" project for each of the plugins? This will force the project to be rebuilt if any of the others change, and you won't have to mess with any other pre/post-build events.
I don't know if this is the right way to do it but you could add a prebuild event to your startup projcet (if it's static) to clean the project which will force a rebuild.
something like:
devenv project.csproj /clean
This is a pain. What we really need is for Microsoft to allow us to hook into a Post-Solution Build event. You can do this via macros but that's too complicated.
I'm assuming this is a C++ project because I don't have this problem with C#.
This is my solution, it's not elegant but it works:
Create a new project whose only purpose is to run the post-build script. Mark it as dependent on every other project in the solution.
Add a dummy file to that project called dummy.h or whatever.
Right click on dummy.h in Solution Explorer and select Properties.
Select 'Custom Build Step'.
For the command line type 'echo' and for Outputs just type 'dummy' or something else that will never exist.
This project, and therefore the post-build script, will now be run on every build.
John.
flipdoubt: they are projects created originally in 2008. My suggestion if it's not working C# is to look in the Build Events tab and check the setting of the "Run the post-build event:" drop down. If it is set to 'When the build updates the project output' this might be your problem, try setting to 'On successful build'.
John.
I'm having the same issue here and it is VERY annoying. John Richardson is right in that there should be a Post-Solution Build event (and a Pre-Solution Build event) that applies whenever ANY project in the solution is being built.
I don't think there is any good workaround to get this outcome in the current VS 2008 IDE.
Starting from #lomaxx suggestion, I got a very similar setup working by adding the following line at the end of the post-build event of the startup project:
"$(DevEnvDir)devenv.exe" "$(ProjectPath)" /clean
Note that this makes the startup project build the next time you need to debug, so you should make sure the project gets built at least once.
PS. I initially tried the pre-build as suggested, but that didn't work (and I think it makes sense - if VS thinks a project doesn't need building, it won't execute any events for that project).