Problem with wsm file deployment

[renatonegrao]

Hi,

I'm trying to deploy a WSM file generated by Proxygen release 10.1B/Windows in a server Linux RedHat with OpenEdge release 10.1A02 using the following command:

wsaman -name wsa1 -wsm ReporteProducao.wsm -deploy

During this process, I got the following error:

Unable to read WSM file: ReporteProducao.wsm (10803)

Does anyone know if this error message is happening due to the difference between the releases used to generate and to deploy?

Is it possible to fix this problem just editing the wsm file?

TIA

Renato

 

[MaximMonin]

Windows:
WSD: <DotNetRuntime>Signed</DotNetRuntime>
WSM: <DotNetStrongNamedRuntime>digitally signed</DotNetStrongNamedRuntime>

Unix:
<DotNetStrongNamedRuntime>false</DotNetStrongNamedRuntime>
You have to change this string in file to import.

 

[renatonegrao]

Thanks MaximMonin for your reply.

I tried without success the following changes in wsm file:

- Removed the key DotNetStrongNamedRuntime;
- Changed the value of DotNetStrongNamedRuntime from false to true, empty and digitally signed;

At wsdl file, I didnt find the key DotNetRuntime.

Do you have another suggestion?

Thanks again.

Renato

 

[MaximMonin]

Well... export wsm file under linux and compare 2 files.
I found this error this way.
I my case it was enough but i used a little diffrent versions of openedge (windows/linux)

 

[renatonegrao]

It's a good suggestion.

But, I didnt find bproxygen in this linux server, and the team responsible for this server doesnt know where is the instalation CD...

Do you know if it's possible to generate the wsm files under linux in another way?

Thanks

Renato

 

[MaximMonin]

try import wsm file through progress expolorer on linux host
then export under linux

and compare

 

[renatonegrao]

Another point...

Before the deployment at Linux Servers, Is it necessary to edit in WSM file the keys related the file System?

Example:

From <WorkDir>P:\work\</WorkDir> to <WorkDir>/u01/work/</WorkDir>

Thanks

Renato

 

[MaximMonin]

No
This path is not used.

when web service works it uses AppServer workpath + procedure relative path defined in proxy gen (check customize button).