|
Hi,
I'm using VS 2005 to create a win32 application.
Now that i have my exe running i'd like to deploy my application and make it run on a dev-free environment.
Does anyone have an idea how to detect the exe dependencies? Of course i've used the dependency walker and i've got a list of dlls that need to sit in the app dir beside my exe. But still, my exe won't run outside visual studio and i get "abnormal program termination".
I'd highly appriciate your help.
Thanks.
Snir.
|
|
|
|
|
You have to execute vcredist_x86.exe on the target machine. This will install the C-runtime and MFC libraries on the target machine. You can download it from here[^] (scroll down if you have SP1 installed for visual studio).
You need of course to distribute the release version of your programs.
|
|
|
|
|
|
It doesn't sound like dependencies are your issue. If I were you I'd build a Release build of your project but switch Debugging information on (Program Database). Make sure your project has the path to the CRT source code ( You did install it with VS 2005 didn't you ) in it's includes. Run the release build and when it tries to quit on you attach the debugger and see if you can figure out what's going on. There are not that many possible causes for "abnormal program termination" on startup so you've got a reasonable chance of cracking it. Did you try to use the CRT file system during static initialization or try to allocate a negative or > 0x7FFFFFFF amount of heap memory? Those are the sorts of things that might silently fail in Debug but may blow you out of the sky in a Release build.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Thanks for your reply.
My release version runs smoothly from within VS. Problems like those you describe would have prevented it from initializing properly even from within VS. Hence my guess that it has to do with the enveloping CRT environment.
Running the exe from outside VS fails! Even on a computer that has a full VS installed.
Snir.
|
|
|
|
|
 The normal expectation would be that running the Release build from within VS and running the Release build on a computer with VS installed are the same thing. You could always try the catchall solution of turning off incremental linking in your project settings and doing a full rebuild. The CRT environment is what's keeling over but that is essentially just a statically linked library or an implicitly linked Dll depending on your project settings ( Make sure if you have multiple modules that the CRT settings are consistent throughout ) Beyond that it's not to easy to get the old veteran that is MSVCRT.DLL to fail in such an arbitrary manner.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Can anybody tell me how I can realize a certain computer?
I mean maybe it's possible to define an unique code for any computer.
|
|
|
|
|
what are you trying to do ?
I really don't understand your question.
|
|
|
|
|
|
Usef Marzbani wrote: I mean maybe it's possible to define an unique code for any computer.
I do not think that you will be able to generate a guaranteed unique value for ANY computer. You might be able to get a "good enough" identifier by looking at a system's hardware and software.
For example, if you want to lock a software application to a certain system, you could look at things that are less likely to change, like:
o Geometry of the Windows System drive
o CPU Serial Number (if supported by the CPU)
o First NIC's hardware address
o results of the CPUID instruction
o Installed Memory
Choosing a value that changes easily, like number of hard drives or drive letters, swap file size, etc., is a sure-fire way to piss off your users if they have to re-validate their license each time this happens.
Peace!
-=- James Please rate this message - let me know if I helped or not!<hr></hr>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
Hi,
Is it possible to embed VERSIONINFO informations in a c# project ?
I tried integrating the .rc file in my project, and modified the generation action to 'embedded resource' but the binary still show the assembly version 
|
|
|
|
|
There is a specific forum for C++/CLI .NET questions and this is not it. Have look at the forum titles.
I have not tried to import an existing RC file but if you create a new C++ managed winforms project it has an RC file which you can add a VersionInfo section into so it is supported some way.
VS2005 on XP Pro
|
|
|
|
|
oh sorry, I was confused where to put this question, so I posted it twice 
yes, you are right! this work in a manged c++ porject, but that's not what I need, I already invested more than 3 months in c# and I am not ready to move to c++ just for this 
|
|
|
|
|
So you are doing C# development? Don't take this the wrong way but in the 44 minutes since your first post I could have have easily manually copied the Version Information values from a RC file into the Version information of the AssemblyInfo.cs file.
|
|
|
|
|
I am sure you can do that 
In my case, I am using a shared version.rc file generated on the fly by the server doing the compilation.. this is getting a little more complicated 
|
|
|
|
|
|
Thanks mike, I appreciate it
|
|
|
|
|
Hi all,
I am writing a program that has a main window with a list control. Upon double clicking an item in the list control, I open a dialog box pertaining to this item (There are a numebr og dialogs in a linked list, of which one is selected). The dialog box is running in a modeless mode, since processing in the main window must continue. When I press the OK button, I send a message to the parent window (I pass the m_hWnd of the main window to the dialog boxes and use ::PostMessage) This message causes the main window to update the list control to reflect possible changes made in the dialog box. I then call "DestroyWindow" for the dialog.
This works fine the first time, but it crashes the second time I enter the same modeless dialog. When I comment-out the postmessage call, then everything works fine, so it seems that this message causes the crash. I can see that it is processed before the crash.
Anyone any suggestions?
Thanks in advance,
William
|
|
|
|
|
Did you use your debugger to pinpoint the exact problem ? This will bring you much more information that we can give you from your post.
|
|
|
|
|
I tried to, but the problem does not occur in the debug version of the program....
William
|
|
|
|
|
William Engberts wrote: but the problem does not occur in the debug version of the program....
The above is a kind invitation to visit [^].
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
I would doubt that the PostMessage itself is the culprit - but the handler in your main window for the message might be.
The other thing to be careful of is that you aren't using the HWND value from the first incarnation of the modeless dialog after it is no longer valid.
Rather than ending the modeless-dialog, you could simply keep it in existence the who time, and just ShowWindow (SW_HIDE /SW_FALSE) it?
Obviosuly what the crash is will have a lot of information for you. You have debugged it and seen how it crashes, haven't you?
Iain.
Iain Clarke appears because CPallini still cares.
|
|
|
|
|
Iain,
Thanks for your remarks. I do not think that the postmessage is the problem either, since I see the results of processing the message which has obviously been sent and processed. The crash occurs somwhere later.
I do not use the HWND of the modeless dialog box at all. I use the HWND of the parent dialog, which remains active all the time. This is the window that has to process the message (write changes to a file and update the list control).
I tried to keep the modeless dialog box in existence (using ShowWindow (SW_HIDE) rather than DestroyWindow. I still send the message before hiding the window, with exactly the same result: BANGGG!!
I did try to debug the darned thing, but then it behaves like an angel. No crashes, however often I enter and destro the subwindows.....
I also found out that it does not matter if I enter the same modeless dialog box twice, or if I enter one and then another. The second OK will make the system crash (in the release version)
William
|
|
|
|
|
Thanks all for your replies. I think I found the problem. There was an issue with the prototype of the message handler function. When I corrected this, the problem had disappeared.
Regards,
William
|
|
|
|
|
You're not allowed to fix the problem yourself! I just read your message in my email, and went "aha! this sounds exactly like the problem I had 9 years ago, with MFC blindly casting the prototype..."
This ended up with stack corruption, and a crash that was very difficult to pin down. And didn't show up in debug mode with its extra padding.
Now you've ruined my chance to show off through your self reliance!
Curses,
Iain.
Iain Clarke appears because CPallini still cares.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
