1,190
Hi there,
I created a new screen using VS 2008, when run that screen in visual studio it seem good and working fine without any issue. But when add that screen into SL its shows the following error msg:
Even i have included the step: Compile->Advance Compile Option->Custom Constants->Win32=True and Target CPU =x86 and .Net FrameWork = 2.0
am using SL7 SP3, Visual Studio 2008, MS SQL Server 2008 R2.
Thanks in Advance,
Karthik
*This post is locked for comments
Also, compile the application to an X86 target CPU. I've had this problem on Windows 7 w/s.
As I noted in the previous post, Dot Net Trust is the other thought that comes to mind.
As I understand it - with the Framework used by 7.0, the default position is that the workstation "does not trust programs which reside on the Server". VBTools screens tend to crash as they load.
Which I think generally makes it relatively easy to see if this is the problem.
If the screen loads successfully when run from local drive c:, but fails when run from a server directory, then dot net trust sounds like a possible cause of the problem.
In recent years, this issue has largely "gone away" because the default position of the Framework used by 7.0 FP1 onwards "trusts the server."
So generally, from 7.0 FP1 onwards, it is not an issue.
But, I'm not quite sure where SP3 fits into this.
As far as I am aware, the standard SL screens do not have this problem because they are digitally signed.
Barry
I'll throw in a couple of thoughts.
One is the "NXCompatFlag issue".
As far as I am aware, it applies only to 7.0 FP1 onwards (and I'm a little unsure about where SP3 fits in.)
But I think VS 2008 may also be relevant.
The NXCompatFlag issue causes errors on screen load, but seems to be extremely variable - on some machines it gives the error, and on others it doesn't.
It does seem that the presence of customizations makes it more likely that the error will occur.
If that is the problem, there seems to be two ways of fixing it, which are actualy two different flavours of the same fix.
One applies the fix as a "post compile" step.
The other patches the .exe after the compile is done.
That's the way I am doing it.
Create a temp folder to work in.
Copy the .exe into that folder.
Create a .bat file in the same folder, containing this code
call "c:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools\vsvars32.bat"
editbin.exe /NXCOMPAT:NO .\*.exe
(You may need to alter those Paths - depending on your Vis Studio install.)
Then run the batch file.
If there are no error displays, and the date/time of the .exe changes, then the patch has been performed.
------------
The other possible cause of your problem that comes to mind is "dot net trust".
I'll post a thought on that separately.
Barry
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
#1
André Arnaud de Cal...
291,280
Super User 2024 Season 2
#2
Martin Dráb
230,235
Most Valuable Professional
#3
nmaenpaa
101,156
Share
Report
All responses (
Answers (