My problem might seem specific, but in fact it is probably very general: How to publish a Console Application that uses 3rd party references?
I am using Visual Studio 2015 to make a Console Application called Gdx2PostgreSql programmed in Visual Basic. The application is reading data in a Gdx-file (output from a GAMS program, www.gams.com) and writing the data to a PostgreSql database. The interface to PostgreSql is handled by NpgSql, www.npgsql.org. NpgSql is referenced as
\\dtu-storage\hela\Documents\Visual Studio 2015\Projects\GDX to PostgreSQL 2\packages\Npgsql.3.1.7\lib\net451\Npgsql.dll
The program functions correctly when it is executed in Debug mode inside Visual Studio.
I have to be able to run the program from the command prompt in a CMD window. Moreover, I have to be able to run the program by spawning from a GAMS program using the GAMS syntax
Execute 'Gdx2PostgreSql "FileName.gdx" "CaseName"';
I have published the program and run the setup file installing the program. But when I run it in a CMD window I get the error:
'Gdx2PostgreSql' is not recognized as an internal or external command, operable program or batch file.
I get the same error message when spawning from my GAMS program.
Being rather desperate I have tried renaming the file setup.exe in the Publish-folder to Gdx2PostgreSql.exe. When I use this file I get:
Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'Npgsql, Version=3.1.7.0, Culture=neutral, PublicKeyToken=5d8b90d52f46fda7' or one of its dependencies. The system cannot find the file specified.
That is, NpgSql is not known to the program.
As I see it, I need to have one EXE-file that holds all what is needed - especially because my program should be able to run on other PCs, too.
Can anyone help me make my program Gdx2PostgreSql function?
Finally, I should mention that I have made other programs reading Gdx-files and using NggSql to write to PostgreSql. These programs function correctly, but they are Windows Forms Applications – and not Console Applications.
Console applications aren't really any different from winforms applications - you have to distribute the EXE along with any DLLs it depends on - in the same directory. As mentioned in the comment, after building your program you should be able to find everything you need under bin/Debug (or Release).
Regarding why your Gdx2PostgreSql isn't being found, that's likely a problem of path - try running your program with an absolute path, or cd'ing into bin/Debug (or Release) before executing it.
Related
I have a simulink model (2016b with MC 2013 C/C++ and Mingw-64 compilers) that I'd like to generate a standalone executable for windows-64 bit.
I was able to run the grt executable but due to the fact that I need to read a mat file runtime as opposed to compile time, I am using rsim code generation for this purpose, however the executable that gets generated appears to need quite a bit of .dll, I provided the dll it was asking for however, the application still unable to run. This is the error that results
The application was unable to start correctly 0xc000007b. Click OK to
close the application
What am I missing ?
Your main program is compiled for x64 (64-bit) target, but the dll you provided is compiled for x86 (32-bit) target. Or vice versa.
If it is Mingw-64 stuff, you should be able to obtain all (or most) of them by using the official online installer. Link is here.
I have memory related problem in my application on solaris9 environment where Tcl_DeleteInterp() function calls lot of free() and mutex_unlock() functions. To debug the problem i followed the below steps to compile tcl on solaris server (with TCL_MEM_DEBUG flag) but still i couldn't use the 'memory' command in my interpreter.
Ran configure script on server (./configure –prefix=<directory needs to be installed> --enable-symbols=mem)
Make clean all
Make install (tcl libraries and tlcsh exe is copied to the path specified in step1)
Compilation generated two libraries (libtcl8.4g.so and libtclstub8.4g.a), I copied libtcl8.4g.so as libtcl8.4.so to my app
Copied tcl8.4 directory as well.
I also copied the tclsh8.4 to $PROVHOME/bin and created soft link as tclsh-> tclsh8.4.
From my application i linked the debug symbol enabled libraries to the place where exactly i created the Tcl interpreter.
Initialized the Tcl interpreter to using Tcl_InitMemory() function (so that the memory command will be registered in the supplied(arg) interpreter.
When i used the interpreter exe (tclsh) separately i could execute the memory command, but when i used the same exe on my application its not working. Can someone help me what could be the possible reason for this problem ?
Also help me how can i cross verify the libraries that they are compiled with TCL_MEM_DEBUG flag.
Will the Tcl source code tar file contain Solaris directory where i have to build the libraries or should i use the unix source code for solaris platform as well ?
Thanks
Are you using [mem] interactively (which does expansion of unambiguous short command names) and forgetting to use the full name ([memory]) in your scripts?
You're using Tcl embedded in your code? You need to call Tcl_InitMemory (passing in the handle to the interpreter where you want the memory command created) after creation of the interpreter and before you run user scripts, i.e., straight after the Tcl_CreateInterp gives you the handle (which should in turn come after the Tcl_FindExecutable call that initializes the shared parts of the library).
You must also make sure that everything is built with that flag set so that the correct memory allocation APIs are used in both your code when it integrates with Tcl, and you must make sure that you are linking against the debugging build. It's probably the linking that has gone wrong, but I've not done that level of development on Solaris for many years.
I think you'll find that “Getting a list of used libraries by a running process (unix)” is relevant to your problems.
I'm trying to learn the basics of dll injection, so I created a really simple hello-world type DLL and an injector based off of code I found online. I wasn't able to find anything that works out of the box, so I had to make a few adjustments.
Injection Code, DLL Code
I'm running these on 64-bit windows. I'm compiling with Visual Studio 2010. The injector is a win32 console app, and the dll is win32 as well. I'm trying to inject my code into an existing notepad process (also 32-bit). All of this is running on Windows 7 x64.
When I run the injector, it fails every time at CreateRemoteThread, with GetLastError returning 5 (i.e. ERROR_ACCESS_DENIED). I've confirmed that the dll path is correct (although changing it to a bogus path gives the same behavior), and I've confirmed that the path is getting written to notepad's memory at the correct address using Cheat Engine. I'm having a difficult time with this because I'm not sure how to debug the problem further.
What could be causing CreateRemoteThread to fail?
The problem is that notepad.exe is a 64-bit process in 64-bit windows, and I was trying to inject with a 32-bit process.
I also come up with the same problem. My situation is this:
My system is 64-bit and the notepad is also 64-bit.
But the injector is the 32-bit process.
My solution is to replace the 64-bit notepad with the 32-bit notepad in the system directory.
I am trying to create a new zend project using wamp.
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\> cd wamp\www\zendtest*
C:\wamp\www\zendtest>C:\wamp\www\zend\bin\zf.bat create project quickstart*
'"php.exe"' is not recognized as an internal or external command,
operable program or batch file.
C:\wamp\www\zendtest>
I the environment variable path is
%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;C:\PROGRA~1\IBM\SQLLIB\BIN;C:\PROGRA~1\IBM\SQLLIB\FUNCTION;C:\Program Files\Zend\MySQL51\bin;C:\wamp\www\zend\bin;
Which is the part I think is wrong.
Replace this line in the zf.bat file
SET PHP_BIN=C:\wamp\bin\php\php5.3.4\php.exe
I too have come across the same Error when i started Zend. Here are some ways how to troubleshoot this.
Make Sure the PHP Interpreter Path (For Example, C:\wamp\bin\php\php5.3.8\bin) is set to the Environment Variables Path. Only one PHP Interpreter can be set.
Make Sure your WAMP Folder & the work directory (For Example, www directory) have valid permission set for proper Execution.
Make Sure your Antivirus/Firewall or any other Software is blocking the Access to php.exe. This i said because, in Windows 7 the User Access Control Feature will not allow execution of php.exe from command line.
And i suggest you work with NetBeans 7.2 which has built-in Support for Zend as well as Doctrine ORM. This is much easier. But you will have to execute the above techniques in that too in the Initial State. The Commands can be directly executed from NetBeans Context Menu.
Came across this error on a new installation even if I added the Environement Path to Windows.
If NetBeans is running, you need to start it as these variables are loaded on startup.
My build script runs on linux and invokes things like gcc, shell scripts, etc.
Part of the solution is written in mono and could be compiled easily on linux.
But I want to obfuscate the code. Not manually, but as part of the build process.
Therefore I need to invoke Dotfuscator and Dotfuscator so far only runs on windows.
Is there a good solutions to invoke command line based workers/build scripts remotely from linux on a windows machine? I don't just want to run a command remotely, but also pass files along.
Like a windows service that is accessed using simple curl-uploads of a tar file, creates a temp folder for each concurrently connected client (or blocks concurrent calls) and unpacks the file, invokes something on these files and packages the result again as tar file to give it back to the caller? And clears the temp file even in case of failures?
Maybe someone knows a good solution that saves me from writing this myself!
It should not be so uncommon that a build process spans multiple platforms, yet common build server answers I found mainly talk about only one build script.
Also think about running e.g. the nsis setup builder from a linux driven build script, if part of your solution has a tiny windows component