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.
Related
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.
Our application is deployed to the target machine with an msi file. All works nicely. Our tester has gone through his plan, and one of the tests requires deleting the application's configuration file. The application is designed to alert the user with a dialog on startup saying "missing config". However, what happens is that - somehow! - the software starts the installer again and retrieves the missing file from the msi! Which is nice, but not what we want. How do we disable that behaviour?
without going into much depth of the windows installer mechanics (if you interested in that there a plenty of articles about this), the shortcut of the software is probably advertised, which means the windows installer checks if everything is in its place before the software is started.
if you can edit the msi, make the shortcut non advertised.
if you can't, install it with DISABLEADVTSHORTCUTS
e.g. msiexec /i myMsi.msi DISABLEADVTSHORTCUTS=1
please note that this is only a quick (and dirty) workaround,
to fix this proper you need to understand the whole windows installer advertising (also called repair or self resiliency) mechanism.
but explaining all the causes and the mechanism of the repair is far beyond this answer and there are quite some articles and posts about that on the internet (and especially on MSDN and stackoverflow)
There is a more correct answer to this, and it is NOT DISABLEADVTSHORTCUTS. You set the component id to null in the MSI file to prevent repair of that individual file. See ComponentId comments here:
http://msdn.microsoft.com/en-us/library/aa368007(v=vs.85).aspx
Edit the MSI file with Orca to delete the Componenty ID, and write an uninstall custom action to delete the file at uninstall if it's there.
In addition, that's a redundant test. Windows will restore that file for you if it's missing, so the idea that you need a test to notify that it's missing is pointless. The true test should be that Windows will restore the file if it's lost, and your app needs to do potentially nothing about the missing file.
You don't mention what tool you are using to make your MSI but I'm going to go out on a limb and guess Visual Studio Deployment Projects (.VDRPOJ).
One of the (many) horrible things about this tool was that it fails to expose the foundational concept of components. Instead it makes every file a key file of it's own component and hides the existence of the component from you. I say 'was' because Microsoft killed this project type in VS. There are around 50k people complaining on UserVoice to bring this tool back and I'm guessing that 49,990 of them don't know what a key path is.
Windows Installer has a concept called the component rules and each component has a keypath. The keypath teaches MSI how to handle repair scenarios. But your tool has to allow you to be able to control this to make it work.
Windows Installer is functioning exactly the way it's supposed to function. You just aren't up to speed on what that is.
However, if you want to ignore Windows Installer best practices and continue using the tool you use today, the trick is to install the app.config file as a different file. Then have the application copy the file to the real file name on run. Windows Installer won't service what it didn't install.
Several answers have been provided that can work:
You can install the file with a blank guid. Then you need to remove it on uninstall using the RemoveFile feature. You will also run into issues if you want to replace it during an upgrade. Could be tricky at times.
You can disable the advertised shortcut(s), but this affects too much in my opinion.
Finally you can use my suggestion to install a separate non-advertised shortcut to use to launch the application. Such a shortcut bypasses the self-repair check. It may still be invoked by other means such as missing file associations, COM registration or similar, but those are exception states.
However, my preference is that an application can start without a config file present, if at all possible. I always suggest a good startup routine with "internal defaults" available. The startup routine should also degrade gracefully if faced with any file system access denied conditions.
Most importantly you should place this config file in the userprofile so you can generate the file on first launch for the user in question. It can even be copied from a read-only copy in the main installation directory.
When you generate a file from internal defaults and put it in a userprofile location, the file will have no interference with Windows Installer at all. The issues that results is how to clean up user data on uninstall. I discussed this with Stefan Kruger (MSI MVP) at one point, and I agree with his notion that user data is indeed user data and should not be automatically dealt with by your installer at all. Leave it installed, and clean it up via system administrator tools if necessary - for example logon scripts.
There is a similar question here on SO, but I have a fairly small solution and I do launch the debugger from within VS. My understanding is that using the Enable the Visual Studio Hosting process checkbox has several advantages so I'd like to keep it checked.
The problem is I will just do a Build Solution and sometimes the MyApp.vshost.exe launches. Then the next time I do a build, the build fails because the .exe is in use and can't be replaced. I then have to Launch Task Manager and manually kill the process (or go the file directory and manually delete the file). Of course now I always leave Task Manager running to save that step.
This never used to happen in VS2008, does anyone know what causes the vshost.exe to launch on a build? I have been extremely careful and have used the Build menu as opposed to the shortcut keys just to make sure I don't hit F5. It also doesn't happen every time but does happen reasonably frequently.
Update
I turned off the checkbox for the visual studio hosting process. When I Debug, exit and rebuild I still see this problem, only now there is no processes listed in the TaskManager. The only solution is to delete the .exe file on disk in the Debug folder and then rebuild. However, the problem happens every time even without running the debugger. That is after every build (without debugging) I have to delete the .exe
I do have Resharper, AnkhSVN, NuGet and NDepend (disabled) installed.
I was also having the same problem. I found a solution that resolved these errors. You need to set the CPU to x86 in the debugging menu. Next to the Debug button on the toolbar, there is a drop-down box that lists Any CPU. Hope so it will usefull to you and resolve your problem.
I set a breakpoint in my code in Visual-C++, but when I run, I see the error mentioned in the title.
I know this question has been asked before on Stack Overflow (Breakpoints cannot be set and have been disabled), but none of the answers there fully explained the problem I'm seeing. The closest I can see is something about the linker, but I don't understand that - so if someone could explain in more detail that would be great.
In my case, I have 2 projects in Visual C++ - the production dsw, and the test code dsw. I have loaded and rebuilt both dsws in debug mode. I want a breakpoint in the production code, which is run via the test scripts. My issue is I get the error message when I run the test code, because the break point is in the production code, which isn't loaded up when the test starts.
Near the beginning of the test script there is a mytest_initialize() command. I imagine this goes off and loads up the production dll. Once this line has executed, I can put the breakpoint in my production code and run until I hit it. But it's quite annoying to have to run to this line, set the breakpoint and continue every time I want to run the test.
So I think the problem is Visual C++ doesn't realise the two projects are related. Is this a linker issue? What does the linker do and what settings should I change to make this work?
Thanks in advance. Apologies if instead I should be appending this question to the existing one, this is my first post so not quite sure how this should work.
[Update 1] I think Chris O has identified the problem. I'll add a further update if I'm able to work out how to use the project settings to make this work.
It sounds like you are using VC6, since you mention dsw files. I think that is as good as it gets in VC6, you have to manually add the breakpoint after your module is loaded from LoadLibrary. Actually, there might be a project debug setting, so you can specify which DLLs to load when debugging your project, that will keep your breakpoints enabled when hitting F5.
You can also try attaching the debugger after you know the mytest_initialize() has been called, that might keep your breakpoints enabled.
I had this issue sometimes, but always pass this with some code replacement actions.
Here is some guy post, how he had fixed it.
Hope it helps.
In my case i solved this by setting the DLL project containing the breakpoint as Active Project and changed Debug settings for this project (right-click project>>settings>>Debug tab) to point to the project that actually runs and accesses the DLL. "Executable for debug session:" and "Working directory:" should be set to the executable that you actually want to run and its corresponding directory.
Hope this is of any help.
right-click project>>settings>>Link tab
check on Generate debug info
check on Link incrementally
I am working on an application that installs a system wide keyboard
hook. I do not want to install this hook when I am running a debug
build from inside the visual studio (or else it would hang the studio
and eventually the system), and I can avoid this by checking if the
DEBUG symbol is defined.
However, when I debug the release version of the application, is
there a way to detect that it has been started from inside visual
studio to avoid the same problem? It is very annoying to have to
restart the studio/the computer, just because I had been working on
the release build, and want to fix some bugs using the debugger having
forgotten to switch back to the debug build.
Currently I use something like this to check for this scenario:
System.Diagnostics.Process currentProcess = System.Diagnostics.Process.GetCurrentProcess();
string moduleName = currentProcess.MainModule.ModuleName;
bool launchedFromStudio = moduleName.Contains(".vshost");
I would call this the "brute force way", which works in my setting, but I would like to know whether there's another (better) way of detecting this scenario.
Try: System.Diagnostics.Debugger.IsAttached
For those working with Windows API, there's a function which allows you to see if any debugger is present using:
if( IsDebuggerPresent() )
{
...
}
Reference: http://msdn.microsoft.com/en-us/library/ms680345.aspx
Testing whether or not the module name of the current process contains the string ".vshost" is the best way I have found to determine whether or not the application is running from within the VS IDE.
Using the System.Diagnostics.Debugger.IsAttached property is also okay but it does not allow you to distinguish if you are running the EXE through the VS IDE's Run command or if you are running the debug build directly (e.g. using Windows Explorer or a Shortcut) and then attaching to it using the VS IDE.
You see I once encountered a problem with a (COM related) Data Execution Prevention error that required me to run a Post Build Event that would execute editbin.exe with the /NXCOMPAT:NO parameter on the VS generated EXE.
For some reason the EXE was not modified if you just hit F5 and run the program and therefore AccessViolationExceptions would occur on DEP-violating code if run from within the VS IDE - which made it extremely difficult to debug. However, I found that if I run the generated EXE via a short cut and then attached the VS IDE debugger I could then test my code without AccessViolationExceptions occurring.
So now I have created a function which uses the "vshost" method that I can use to warn about, or block, certain code from running if I am just doing my daily programming grind from within the VS IDE.
This prevents those nasty AccessViolationExceptions from being raised and thereby fatally crashing the my application if I inadvertently attempt to run something that I know will cause me grief.