After upgrading from Prosight V6 to V7.5 we are having issue with API's

Question

Team,
Current version 6 of prosight upgraded to version 7.5. We are having our external webservice consumes Prosight webservice which defaulted installed under ProsightWS virtual directory. After up gradation we are running into issue in external application ,application unable to communicate to Prosight new version webservices. Fails in the time of calling in Login method itself in the psPortfoliossecturiy service.
Exception as follows:
“System.Web.Services.Protocols.SoapException: Could not create Security Token for specified User and Password at ProSight.Portfolios.WebServices.WS.psPortfoliosSecuritySOAP.Login(String sUser, String sPassword, Int32 lTimeOut) “
Our web application uses a dedicated user account to interact with Prosight webservice and it runs under windows authentication. Application build on ASP.NET 2.0 and later.
The sad part here is , our web application running perfectly with Prosight v6. :( I would appreciate if anyone could help us to resolve this issue. This is blocking our up gradation from 6 to higher version of prosight.
Thanks for your valuable time
Regards,
Jithesh

Answer 1

Here is the offical documentation from version 8.0 on the backward-compatability of the APIs. This document comes the version 8 installer. Not sure this helps you with the 7.5 issues, but hoping it will help:
Considerations for applications using the PPM Open API via COM
Applications which use the Primavera Portfolio Management (PPM) Open API via any interface (COM, SOAP/RCP or Document/Literal) and were developed and used with previous versions of PPM will continue to operate without the need for recompilation, as Primavera Portfolio Management 8.0 provides full binary backwards compatibility for all of the Open API interfaces. New functionality is available only to applications that are written to take advantage of such functionality.
Note however that any process can only load and use one version of the Microsoft .NET Framework. Therefore, applications developed with the .NET Framework 1.1 cannot use APIs to communicate with software developed using the .NET Framework 2.0 if this would cause the same process to need to load both versions of the .NET Framework.
This means that if any part of an application that uses the Open API which was developed using .NET Framework 1.1 communicates directly with PPM using the COM API (which is in-process), that part of the application would need to be recompiled to target the .NET Framework 2.0. If on the other hand, the application developed using .NET Framework 1.1, only communicates with PPM using SOAP RPC or Web Services (which are out-of-process) then there is no issue.
Instead of recompiling, it is usually sufficient to ”force” the existing executables to actually use the .NET Framework 2.0 instead of the native version of the .NET Framework for which they were compiled (1.1). This can be achieved by using an application config file with the following content:
<?xml version ="1.0"?>
<configuration>
<startup>
<supportedRuntime version="v2.0.50727" />
</startup>
</configuration>
The application config file can easily be created using Notepad or something similar. It does not need to be compiled in any way. It should be named with the exact same name as the executable file plus the suffix “.config”. For example: if the application executable file is called “Tester1.exe” then the config file must be named “Tester1.exe.config”. It must be placed in the same directory as the executable file.
The config file “forces” the application to use the .NET Framework 2.0, which would mean that even when using COM (in-process) Open API calls to PPM, there would still be only one version of the .NET Framework involved in the process (.NET 2.0).
----------------------------------------------------------------------------------------