Wednesday, May 22, 2013

Community

Forums

Recent Forum Posts

RE: download page where?

RE: Hanging protocol to improve work flow

RE: worksatatin v3 files

Cine speed too slow?

RE: Transferring Images for patients

RE: Ask about server to server connection

Unexpected error when reading file

RE: CC ImageServer PROBLEM

RE: how image inverting be saved as presentation state?

RE: DICOM Compression

Our Community

	Membership:
	Latest: eng.mariam.yosef
	New Today: 2
	New Yesterday: 13
	Overall: 28659

	People Online:
	Visitors: 12
	Members: 0
	Total: 12

ClearCanvas Community Forums

We've moved our Developer Forums!

To better assist our open source community, we have moved our repository and developer forums to GitHub. You can access the new developer forums on our ClearCanvas GitHub issues board.

Unanswered Active Topics

Forums

Forums > Developers (Forum closed - Read only) > General

C++ assembly loading

Last Post 2012-05-29 12:40 PM by steve. 9 Replies.

Sort:

	Prev Next
You are not authorized to post a reply.

Author

Messages

postb99

Senior Member
Posts:166

2012-05-02 10:24 AM
Hello, I'll give a try to a more recent code checkout that what I work with (before svn to mercurial migration) but don't think the problem is related to base code, correct me if I'm wrong. I have troubles with following : I launch an application and CC's PluginManager looks for plugins (method : FindPlugins, use of Assembly.LoadFrom(strPath)). When it encounters ClearCanvas.Dicom.Codec.Jpeg.dll : - if called from an NUnit test, the dll loads correctly and the plugin is added to list of plugins. - if called from asp.net application, the dll loading throws a bad image format exception and thus I don't have this codec as an available plugin... Some technical details : - I use VS 2010, framework .NET 4 - For the unit test project, every useful dll (CC's C# code or C++ codecs) are all in [my project]\bin\x64\Debug directory. Unit test calls my C# code which calls ClearCanvas. - For the asp.net project, I put ClearCanvas.Common.dll into website's bin directory, and all the other C# or C++ dlls into a directory named "plugins" besides "bin", because dlls are found if I setup like this. I did debug. - The asp.net project is a very simple site : it references a WCF service, with a .svc file. It is useful to expose the WCF over http protocol when hosted in IIS (7). Now I'm doing local tests without IIS, only two instances of VS 2010, one running the website with WCF, the other one running what I need to call the website with WCF on its .svc url. - I did another test, tell my main app to directly call WCF hosted by VS (main app and WCF are launched at once in a VS instance) : I have the same behavior than with unit test case : all dlls are in same directory and Jpeg codec C++ dll loads fine. Thanks for any explaination and solution... my goal is to make call to WCF work in test environment (IIS hosting). If I cannot achieve this, I will host my WCF as a Windows service on test server... Barbara

chafey

Veteran Member
Posts:120

2012-05-02 11:48 AM
I am also using CC 2.0 SP1 compiled for .NET 4.0 under an ASP.NET MVC 3 application. I ran into similar problems and ultimately disabled the plugin loading code and manually referenced the codec dlls from my project. I know the plugin code was revamped in the latest so this may be fixed, but I haven't tried it yet (very much looking forward to the new open source release!). Since you are getting bad format exceptions, it may be that you are using 32 bit codecs in a 64 bit app pool (or vice versa). Make sure these are matching.

postb99

Senior Member
Posts:166

2012-05-14 02:50 AM
Hi Chafey, Did you write some custom code to tell the application to use a spcific codec class for a specific file transfer syntax ? Or juste disable PluginManager to load any plugins, but then how would the system find a plugin it's looking for ? And a codec ? I use a 64 bits system and took care of using the 64 bit codecs dlls. A co-worker told me that is is normal that a call to Assembly.LoadFrom(some path) will fail with a managed C++ dll... I will double check 32/64 bit related things. I hope I don't have missed a case where I would be in 32 bit rather than 64 bit like expected. Thanks. Barbara

chafey

Veteran Member
Posts:120

2012-05-14 07:46 AM
Here is what I did: 1) Comment out PluginManager.LoadPlugins() 2) Added the codecs as references to my main application 3) Called a method in each codec plugin from my main application to make sure the linker doesn't strip out the dll reference when linking (e.g. for Codec.Jpeg2000.dll i just called the constructor on DicomJpeg2000LosslessCodecFactory) The extension point mechanism works off of DLLs loaded into memory. Since the DLLs get loaded via step #3, everything works like it does when it gets loaded via the PluginManager.LoadPlugins(). Don't forget to make sure the app pool assigned to your web app is set to run in 64 bit mode Chris

steve

Senior Member
Posts:2096

2012-05-14 09:13 AM
Chris & Barbara, Note that the new general release will be built on VS2008 and not VS2010. (The new release is based on the Cheetah branch.) The release will only be for the Workstation, and not the RIS or ImageServer. Our move to VS2010 is for a different closed source project, although we are making an attempt to make sure the open source solutions still build. Steve

Live and real-time support available for Personal, Team, and Cleome Edition customers.

chafey

Veteran Member
Posts:120

2012-05-14 09:59 AM
Steve - a few questions about this: 1) Why isn't the image server being released? 2) What are your plans for future open source releases of the image server and workstation? 3) What are your plans for these future releases to be based on VS2010/.NET 4.0? I realize all comments on the future are subject to change, but there are a number of things I would like to contribute and am just trying to figure out when I should do them (I am purely in VS2010/.NET4.0 world and don't want to go back to VS2008/.NET 3.5) Chris

postb99

Senior Member
Posts:166

2012-05-22 08:44 AM
Hi again, What is the difference between the Marmot and Cheetah branch ? I checked out Marmot branch, converted it to VS 2010 format and it (Dicom, ImageViewer, and ImageViewer.Volume.Mpr, mainly) works well with my project. I pinpoined the initial problem I have : it is clear that when running dicom processing (image extraction) code within a WCF service that is accessed by http://someserver/someurl.svc uri, the CLR runs in 32-bits mode. The webservice+WCF is run from VS 2010 development server. My development machine is a 64-bit one. So I have to find out what happens, because even when I can feed my project with all available codecs (32 and 64 bits) and it (PluginsManager, extension points lookup) would load half of them, it would be the wrong way willing to do the same things for MPR, I guess. Barbara

postb99

Senior Member
Posts:166

2012-05-22 09:07 AM
I played with build configuration. My projects were targeted to "AnyCPU" platform. I targeted them all to "x64" platform. When launching the web service project, it failed to load the WCF project dll. I have to have the following projects targeted to Any CPU instead of x64 : ClearCanvas SDK projects, my Dicom processing class library, my WCF project, my webservice project. I read on the internet that VS WCF host process is purely a 64-bit one. It is indeed so when looking at process manager. Asp.net development server is also 64-bit while VS itself is 32-bit... Now I'm going to give some tries with IIS and a dedicated 64-bit app pool.

chafey

Veteran Member
Posts:120

2012-05-22 01:06 PM
The ASP.NET Web Server (Casini) that comes with VS2010 is 32 bit only. You can develop/debug in 64 bit mode by running it under IIS and setting the app pool to 64 bits. I have been using IIS Express 7.5 instead of the ASP.NET Web Server but it is still only 32 bit. IIS Express 8.0 is in beta and supposedly supports 64 bit debugging, but I haven't tried it yet.

steve

Senior Member
Posts:2096

2012-05-29 12:40 PM
Chris, Sorry for the delay, in response to your post below, here's some comments: 1. We had hoped to have the ImageServer release by now, but due to other business priorities, we just haven't found the time to release it yet. There has been 4 commercial releases of the ImageServer since the 2.0 release and also a number of commercial releases of the Workstation. The milestones for all of these releases have been in mercurial, so there have been stable code bases that you could build off if desired. 2. We do have another Workstation release coming up, as Norman mentioned here. It is the only public release of the Workstation scheduled, although we've only planned our next couple of releases at this time. As Norman mentioned, we're on track to complete the Workstation soon, however, there's some operational issues that we're behind on that will take some time to complete before the official release. In any case, this next release is based on the Cheetah branch in Mercurial. 3. The "Cheetah" branch being developed for the next Workstation release and it will be based on .NET 3.5 & VS2008. The Marmot branch is where the updates to VS2010 & .NET 4.0 are being done. Note that this branch is focused on the Workstation, and although we've updated the ImageServer solutions to use .NET 4.0 & VS2010, we didn't really test them. After this, our future releases will be using .NET 4.0 & VS 2010. We do anticipate making a quicker transition to VS2012 after its released than we did with VS2010. As for when to contribute, I would suggest either contributing based on the Marmot branch, or waiting until we merge that branch into the default branch (which will probably happen sometime in June). Steve

Live and real-time support available for Personal, Team, and Cleome Edition customers.

You are not authorized to post a reply.

Forums > Developers (Forum closed - Read only) > General

Active Forums 4.1

Privacy Statement