I'm trying to run the demo code for suave (a webserver) in Xamarin Studio 5.9.8 on OS X El Capitan.
module ServerTest =
open Suave // always open suave
open Suave.Http.Successful // for OK-result
open Suave.Web // for config
startWebServer defaultConfig (OK "Hello World!")
It works as expected when I actually build the code. But when I try running it interactively, with ctrl + return, I get the error The namespace or module 'Suave' is not defined. I've looked around, and it looks like it's possible to use libraries interactively with Visual Studio. Is there a way to get this to work on OS X?
When you build your code, the information about referenced DLLs is contained not in the code itself, but elsewhere (the project file).
But when you execute the code in FSI, all FSI sees is the code. It doesn't have a project file from which to get references.
But since FSI still needs to load referenced DLLs occasionally (otherwise, it wouldn't be very useful), it offers a way to encode them in the code. This way is described in the page you linked - specifically, the #r directive.
Unfortunately, these directives are not supported when you build the code with the compiler. The compiler will generate an error when it sees them.
So it would seem that you have a choice: either execute the code with FSI or build it with compiler. Can't use the same code for both.
Fortunately, there are a couple of tricks to work around this.
First, you could leverage a special conditional compilation variable called INTERACTIVE and put the #r directive inside an #if such that only FSI will see it, but compiler won't:
#if INTERACTIVE
#r "./path/to/my.dll"
#endif
Second, you could create a separate script file that will load references and then load your actual code file:
#r "./path/to/my.dll"
#load "./my_code.fs"
And then execute this script file with FSI.
In both these cases, the paths are relative to the script file.
This means that the "not found" error you're getting is probably due to incorrect path to the Suave DLL. I seriously doubt that the DLL is located in the same directory with the code file. And also that it has no extension.
Related
I want to build C++ desktop applications using visual studio and wxWidgets on windows 7. I'm coming from C++ Builder.
I downloaded and built the wxWidgets libraries successfully and I can run the minimal_vc14 solution just fine. Now it comes time to create my Hello World app. I've created a new, empty C++ project and using NuGet added the wxWidgets template. Then I use class wizard to add a new class (Test3) with a base class of wxApp.
I immediately get 45 errors. The first of which is
Severity Code Description Project File Line Suppression State
Error (active) cannot open source file "../../../lib/vc_dll/mswud/wx/setup.h" Test3 c:\wxWidgets-3.1.0\include\msvc\wx\setup.h 121
digging into that file I find the following bit. The last include statement is the problem line identified above, but the problem I think is in the wxConcat6 statement. All of those ../ lead nowhere. Shouldn't that point to $(WXWIN)?
// the real setup.h header file we need is in the build-specific directory,
// construct the path to it
#ifdef wxSUFFIX
#define wxSETUPH_PATH \
wxCONCAT6(../../../lib/, wxLIB_SUBDIR, /, wxTOOLKIT_PREFIX, wxSUFFIX, /wx/setup.h)
#else // suffix is empty
#define wxSETUPH_PATH \
wxCONCAT5(../../../lib/, wxLIB_SUBDIR, /, wxTOOLKIT_PREFIX, /wx/setup.h)
#endif
#define wxSETUPH_PATH_STR wxSTRINGIZE(wxSETUPH_PATH)
#include wxSETUPH_PATH_STR
Also, smaller problem but further up the setup.h file I see that WXUSINGDLL has been defined, but I want to use libs. I can't figure out where that is being set either.
Obviously there is a configuration step I missed somewhere. Please advise.
As usual the answer can be found by reading EVERYTHING.
There are 2 things that need to be configured for this process to work correctly.
After creating the project go to the project properties and set the character set to Unicode. The default is Multi-Byte. My next quest will be to find where to change the default!
After installing the package template (or is it a template package?) go to the project properties and set shared to "statically linked build".
Presto changeo, you are ready to go. Add the following for the absolute minimum to make a compilable application. This is based on the tutorial here:creating-wxwidgets-programs-with-visual-studio-2015
bool MyProjectApp::OnInit()
{
wxFrame* mainFrame = new wxFrame(nullptr, wxID_ANY, L"MyProject");
mainFrame->Show(true);
return true;
}
wxIMPLEMENT_APP(MyProjectApp);
I suggest you make a copy of minimal sample (or widgets, as it uses more controls and links more libs), in the same location, and modify the source file as you need.
When you have played enough with it, for sure you'll find it quite easy to change the project file so that it'll use $(WXWIN) or any other custom settings.
p.s. I don't know what "wxWidgets template" from NuGet contains, but I strongly doubt it is provided by wxWidgets maintainers.
I've created Qt project using Visual studio 2012 32 bit and Qt5 SDK with the help of Visual studio Qt addon. I'm using Windows 7 ultimate OS.
I have created QApplication GUI Project which basically uses the following libraries:
qtmain.lib
Qt5Core.lib
Qt5Gui.lib
Qt5Network.lib
Ws2_32.lib
Winhttp.lib
Winmm.lib
Qt5Widgets.lib
Qt5PlatformSupport.lib
imm32.lib
And I have succeed in building the application binary without any errors.
I’m trying to run this application on test machine windows 7 desktop having following dlls copied there:
icudt51.dll
icuin51.dll
icuuc51.dll
libEGL.dll
libGLESv2.dll
Qt5Core.dll
Qt5Network.dll
Qt5GUI.dll
Qt5Widgets.dll
qwindows.dll [copied from msvc2012\plugins\platform folder ]
I’m getting the error:
Failed to load platform plugin “windows”. Available Platform are : while trying to run the application.
What would i have missed? How to make it run on windows platform? Please Help me to troubleshoot this.
I've followed the links posted about this problem previously. but none of them are solved my problem. What configuration I am missing?
The platform plugin dlls would need to be put into the platforms subfolder and then it will work.
Yet another solution: Early in your main function or whatever, call QCoreApplication::addLibraryPath(). A simple example:
std::ifstream configurationStream("whateverNameYouWant.conf");
std::stringstream configurationText;
configurationText << configurationStream.rdbuf();
auto ct = configurationText.str();
if (!ct.empty())
QCoreApplication::addLibraryPath(QString::fromStdString(ct));
Here I load the path from a .conf file of my own invention, so that the path won't be hardcoded into my program. Since I invented this file, I control its format; in this case it contains nothing but the path. The actual path I'm using is C:/qt5/qtbase/plugins; that directory contains platforms/qwindows.dll and other such files. One may adjust the paths for one's own case according to where one's Qt files are installed.
I guess it is also supposed to be possible to use a standard qt.conf file, using a format specified by Qt, to automatically load some special paths (including this plugins path) without having to add special code to your own program for the purpose: http://doc.qt.io/qt-5/qt-conf.html ...But I haven't ever managed to get that to work, for whatever reason. Maybe I'm making some simple mistake, I dunno.
An other solution is to add arguments to the QApplication object (or to the starting application).
For instance, you want to load qwindow.dll from C:\test\platforms.dll, you can instanciate QApplication object with the following code :
int ac = 4;
static char * av[] = {"myappli.exe","C:\\\\path\\to\\myappli.exe","-platformpluginpath","C:\\\\test"};
m_qApp = new QApplication(ac, av);
Be careful, the QTCore dll can't be into the directory C:\test (loading dll conflict)
If you specify a working directory different than the one where your executable is located, no matter the plugins are there, it will fail.
So, in that case, copy your file with a post build event.
And in:
Configuration properties->Debugging->Command
specify the full path of the executable.
This was tested on VStudio 2008.
When dynamically referencing assemblies in .fsx using #I and #r, VS highlights the following usages of imported types and writes "The namespace or module 'XXX' is not defined". Is it ok?
For example, in the following code
#I #".\Tools\FAKE"
#r "FakeLib.dll"
open Fake
Target "Hello" (fun _ -> trace "hello!")
Run "Hello"
VS highlights Fake and says "The namespace or module 'Fake' is not defined", it also highlights Target and Run. I have this problem in VS 2010 SP1 and in VS 11 CTP. This issue makes writing F# scripts a bit harder task than it could be.
By the way, IntelliSence for "common" types works well. FakeLib.dll and FakeLib.xml are present in the .\Tools\FAKE directory. The code runs well.
Update 1
Here's the screenshot of the situation. You can see that VS resolves assembly FakeLib correctly (in a tooltip), and that at the same time Intellisense "see" standard types (tooltip over Console) class.
Update 2
I think there's something wrong with the IntelliSense on my work workstation, because it (IntelliSense) behaves itself quite strange. When I start VS and open .fsx file, IntelliSense refuses to resolve even standard types/classes, and it doesn't underlines FAKE classes, it does nothing. But after some period of time and some manipulation over code IntelliSense starts working for standard types and underlines FAKE types.
Moreover, when I've created the similar code on my home workstation there were no problems, IntelliSense works as it should.
If you put the full path into the #r directive, you'll get full IntelliSense. The #I directive, while convenient, prevents IntelliSense from working properly though the code will run just fine. This is true for both loose scripts and those found in projects. Have a look at Tomas Petricek's [FSharp.AsyncExtensions](http://github.com/tpetricek/FSharp.AsyncExtensions] project.
No, that's not how it works. Does your code run? Intellisense is provided for assemblies referenced using #r.
I can't seem to understand how it works.
I see there is an option /assembly available to the Script# compiler which procuces a .dll file with the .js file as a resource. Here is an example from http://www.nikhilk.net/ScriptSharpIntro.aspx:
ssc /ref:sscorlib.dll /ref:Script.ScriptFX.Core.dll /debug /assembly:HelloWorld.dll /out:HelloWorld.js HelloWorld.cs
Can I get the same result using Script# Visual Studio templates? How do I enable this option for my Script# project?
There isn't a way to produce an assembly with script embedded in it.
I think the /assembly flag might be a remnant, or is there primarily for the script# compiler to know where the assembly produced from the same code as produced by the c# compiler exists.
If you want to embed the script in that assembly, you'll need to do a two pass c# build - in pass 1, there is a placeholder script, and then in pass 2, the real generated script.
Alternatively I can think of some approaches involving ildasm, add script resource reference, and then ilasm'ing to get back a new assembly.
What is your scenario? I am curious. I've debated whether to make the two pass build be supported out of the box... but never gotten around to it, since the embedding a script was a nice-to-have.
I have recently edited a fellow student's data collection software to my specifications. The program works fine when I run within Visual Basic 6, however ideally I would like to compile the program into an .exe file so I can run it from any PC. However, when I select the option to turn it into an exe, I get the following error while its compiling:
Compile Error: Sub or Function not defined.
I was curious why my program will run from within Visual Basic, but can't compile into an exe. Any fixes/suggestions would be greatly appreciated!
You must just be running the app in the IDE by using Start (F5) - this does not do a full compile so won't catch all compile errors. I suggest you always use Start With Full Compile (Ctrl+F5) - then it will show you where the errors are.
You can create a custom control bar button to do the Start With Full Compile - saves typing CTRL+F5 all the time.
at the begining of every file, write "option explicit". This changes vb behavior from weak typed to strong typed.
What this means is that when you put a string into an integer, then the vb will tell you right away, or at least when you press "run". In a weak typed mode, the program will run until it encounters a fault, like "Sub or Function not defined" then crash.
When you compile into an "exe", vb needs to do extra sanity checks much like "option explicit" would do. This is why you don't see the problem while normal execution. It is still there, lurking, but you probably don't execute the problematic line.
It is very important that you use this keyword in every vb source file you have, otherwise you'll see problems like this all the time.
It allows you to run the program even though it won't compile due to the Compile On Demand feature the IDE supports. As noted in other posts you can CTRL-F5 to do a full compile, or you can go into Options --> General and turn off Compile On Demand...(saves a lot of CTRL-F5s)