| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| .NET Compute Node DLL References |
« View previous topic :: View next topic » |
| Author |
Message
|
| Dave Ziegler |
 Posted: Mon May 19, 2014 1:42 pm Post subject: .NET Compute Node DLL References |
 |
|
Centurion
Joined: 15 Apr 2014
Posts: 118
|
If I have a .NET Compute Node and it references a DLL, and that DLL references another DLL, what are the correct steps to take in order to get both DLLs imported into my workspace so that I can attach the VS debugger and be able to step into the code for both DLLs?
I've accidentally gotten this to work, but now I've started another project and cannot for the life of me figure out how to get that second DLL recognized. |
|
| Back to top |
|
 |
| mgk |
| Posted: Tue May 20, 2014 3:10 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
Hi Dave.
To import dependent dll's you should be able to right click on the .NET ApplicationDomain reference under your Application in the toolkit and choose "Import .NET Resources". Then you can import anything that needs to be present for the AppDomain to be run after the deploy (config file, other assemblies etc).
However, it's worth pointing out that deploying .NET Assemblies in the BAR file is optional and it works best when used for deploying into Test/QA/Prod environments. For Dev systems where you are still editing the .NET code, it is more efficient to specify the full path (on the local machine) to the main assembly in the assembly reference on the .NET compute node. Normally in dev this will be located in the "debug" output folder that Visual Studio puts the assembly into when it is built. Then, you deploy the flow without deploying the assembly along with it and the runtime will pick up the assembly in the location specified and treat that folder as the "App Domain Base". This means that if you rebuild the Assembly in Visual Studio, the runtime will see the change and automatically "Hot Swap" the old assembly out (by unloading the app domain) and load the new assembly for you without needing a redeploy of the flow. This speeds up the development time for making the assembles.
This Hot Swap process is explained with examples as part of this article:
http://www.ibm.com/developerworks/websphere/tutorials/1202_thompson4/index.html
I hope this helps,
Kind regards,
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| Dave Ziegler |
| Posted: Tue May 20, 2014 5:16 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2014
Posts: 118
|
| mgk wrote: |
| To import dependent dll's you should be able to right click on the .NET ApplicationDomain reference under your Application in the toolkit and choose "Import .NET Resources". Then you can import anything that needs to be present for the AppDomain to be run after the deploy (config file, other assemblies etc). |
Yes, this is what I've been doing. I've also tried just "import" from file system which seems to do the same thing, but maybe not? Either way though, only DLL 1 ever appears in the navigator for me, and the only way to see any other .NET DLLs I've imported is view the BAR file in GeneratedBarFiles. Maybe there is another way?
| mgk wrote: |
However, it's worth pointing out that deploying .NET Assemblies in the BAR file is optional and it works best when used for deploying into Test/QA/Prod environments. For Dev systems where you are still editing the .NET code, it is more efficient to specify the full path (on the local machine) to the main assembly in the assembly reference on the .NET compute node. Normally in dev this will be located in the "debug" output folder that Visual Studio puts the assembly into when it is built. |
Yes, this is a lot simpler. We logged a PMR early on and forgot about that bit of guidance until yesterday. Thank you.
| mgk wrote: |
Then, you deploy the flow without deploying the assembly along with it and the runtime will pick up the assembly in the location specified and treat that folder as the "App Domain Base". This means that if you rebuild the Assembly in Visual Studio, the runtime will see the change and automatically "Hot Swap" the old assembly out (by unloading the app domain) and load the new assembly for you without needing a redeploy of the flow. This speeds up the development time for making the assembles.
|
One thing I've noticed, and maybe this is a problem with VS2013, but in this situation only the breakpoints in DLL 1 show as active until I actually start stepping through my code. Once I step into DLL 2, even though the breakpoint does not appear active and the warning indicator is next to it, you actually can step into the code. That was a little confusing yesterday.
Also, what is the purpose of specifying the location of the .csproj file in the Visual Studio tab? Set or unset, I couldn't tell the difference.
Thanks again. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
