MF COBOL App.Config file missing - cobol

App.Config not found message when calling C# program from MF COBOL using Net Express 3.1, where should it be placed? C# program goes to URL to do an OFAC check with parameters passed.

Related

CsvProvider type not defined

I'm attempting to use CsvProvider for f# but it says the type isn't defined even though I'm importing FSharp.Data.
open FSharp.Data
type test = CsvProvider<"C:\\First_Names.csv">
I'm not using the interactive scripts. This is an .fs file. It doesn't tell me that FSharp.Data can't be found. It was even in the intellisense.
What are some ways I can diagnose this problem, because I'm at a loss now.
This is probably due to the fact that you either having FSharp.Data.SqlClient referenced or FSharp.Data.TypeProviders (from the F#3 distribution). Both use that namespace hierarchy.
This is the same as how namespaces work in C# or VB .NET.

how to decompile an .exe file which is not a .net module

I am trying to decompile a file called App.exe. When I am trying to decompile this file using reflector it's getting an error that App.exe is not a .Net module.
Seeing this image you can get a idea that what I am trying to say:
Then I tried to check what language this file's written in using CFF Explorer. For App.exe it's showing this:
And for VSM.exe it's showing:
The two files are created by one company only but I cant understand why it is not decompiling.
Can't a .exe file which is not created in .NET be decompiled?
Here's article about decompiling Delphi applications: http://delphi.about.com/od/devutilities/a/decompiling.htm
It's a lot harder process than with .NET programs. What you're trying to achieve?
Best results are obtained with IDR (Interactive Delphi Reconstructor) and IDA (the Interactive Disassembler) and PE Explorer (for forms/dfm)
The application is not a .NET application, meaning it was compiled using a different compiler. So there will be no IL (Intermediate Language) elements for reflector to reflect on. This is exactly what you should expect.
You might start with Depends.exe
use protection_id.exe to determine the http://pid.gamecopyworld.com/
Compiler, and
Protector/Packer
Depending upon the compiler, there are various option, like
Ollydbg, DeDe, Interactive Delphi Reconstructor, IDA, etc
I would prefer DeDe for Delphi.

Can the F# core libs be SQLCLR-approved?

According to this thread, F# Core must be SQLCLR-approved for assemblies to be marked SAFE. Is this planned? Can it even be done?
I believe it can be done. However, F# core library is the sole property of Microsoft. This means you can't modify its code and recompile it to match and comply with SQLCLR SAFE. I suggest you add suggestion to Microsoft using Microsoft's connect website.
Microsoft connect is at: http://connect.microsoft.com (you have to register and have email account on live.com or hotmail.com before register).
To manually add your .NET DLL and integrate it to SQL Server, you can do this:
In this example, the DLL from your F# code has to be compiled first. I take this step from MSDN Library link:
http://msdn.microsoft.com/en-us/library/ms254956(v=vs.80).aspx
Just don't forget to add PERMISSION_SET = SAFE to the CREATE ASSEMBLY command.
Here are the steps I quote from above link:
Loading and Running the "Hello World" Stored Procedure in SQL Server
Once the sample procedure has successfully
compiled, you can test it in SQL
Server. To do this, open SQL Server
Management Studio and create a new
query, connecting to a suitable test
database (for example, the
AdventureWorks sample database). We
will need to create the assembly so we
can access the stored procedure. For
this example, we will assume that you
have created the helloworld.dll
assembly in the C:\ directory. Add the
following Transact-SQL statement to
your query.
CREATE ASSEMBLY helloworld from 'c:\helloworld.dll' WITH PERMISSION_SET = SAFE
Once the assembly has been created,
we can now access our HelloWorld
method by using the create procedure
statement. We will call our stored
procedure "hello":
CREATE PROCEDURE hello
AS
EXTERNAL NAME helloworld.HelloWorldProc.HelloWorld
Once the procedure has been created,
it can be run just like a normal
stored procedure written in
Transact-SQL. Execute the following
command:
EXEC hello
This should result in the following
output in the SQL Server Management
Studio messages window.
Hello world!
Edit: based on the commenter below, he's right about F# is now open source! You can modify and recompile it to suit your needs.
Edit: adding more detail guide on how to integrate the DLL to SQL Server CLR integration.
A trick, as nasty as it is, would be using the --standalone flag of fsc (aka the F# compiler). This can even be added in the project settings and embeds in the output artifact the F# runtime library (along with all other dependencies deemed embeddable). I believe that at that point you should be able to do exactly what you want just by marking your assembly as SQLCLR safe.

Can I access types created in F# Interactive with System.CodeDom?

I am creating my type in FSX and passing those types into the Razor templating engine with the open source RazorEngine project.
Hosting Razor outside of ASP.NET requires compiling the Razor templates. If I pass a model created in FSX into the template, will System.CodeDom be able to have access to that type created by FSI? The basic error that I get is "The type or namespace name 'FSI_0004' could not be found".
Code that's compiled using System.CodeDom cannot generally have access to the code loaded in F# Interactive - the CodeDom essentially writes the C#/F# source code to disk and then invokes the command line compiler on the code (and the command line compiler cannot reference code loaded in F# Interactive).
There may be a way to get it working though - You could use the F# CodeDom provider from PowerPack. You could modify it to generate the source code (as it currently does) and then send the generated code to F# Interactive (instead of invoking command line compiler). This way, the code compiled on-the-fly could see F# Interactive code.
There are some issues that need to be resolved
Is it possible to provide your own CodeDom provider to RazorEngine?
The F# CodeDom provider may not correctly handle code generated by Razor (so you may need to fix/workaround a few things in the F# CodeDom provider). You may also need to modify it to generate code that works nicely with F# interactive (e.g. remove top-level namespaces)
What instance of F# Interactive do you want to use? (And how to get standard input, so that you can send your code there)
Do you need to load the compiled assembly and pass it back to Razor? I'm not sure if this can be done with F# Interactive.
These all depend on your scenario - but I guess that it may be possible to get what you want (possibly with some workarounds).

How to manually invoke DSProxyGEN.EXE to generate Delphi DataSnap proxy client?

I am using DataSnap of Delphi 2010. There is a DSProxyGen.EXE utility to allow us generate proxy client unit. Does anyone how to consume this utility in command line to generate the proxy client without using TSQLConnection's context menu?
DSProxyGen doesn't give you its parameters when run at the command line and doesn't respond to
DSProxyGen /?
You could try replacing it with your own exe (make a backup!) that detects what command line parameters are sent (global CmdLine variable) and write them to a file. Launch this from TSQLConnection's context menu and you should have what you need to call DSProxyGen from the command line.
Update:
From Delphi XE to XE7, source code for DSProxyGen is included as one of the samples
Samples\Delphi\DataSnap\ProxyGenerator
In Delphi XE8, it is shipped as part of the source code.
source\data\datasnap\proxygen
DSProxyGen.exe without arguments connects using TCP/IP port 211 and uses the first command-line argument as filename.
DSProxyGen test.pas
Will generate test.pas
I've found no way to specify ConnectionString options on the command-line, yet...
It is possible with the DSProxyGen.exe from Delphi XE and later, for example:
DSProxyGen.exe Proxy.pas
-C:host=localhost;port=8080;communicationprotocol=http
Run DSProxyGen.exe without parameters for usage help. (/? or /h etc. does not work)
I've noticed the source is also included in Delphi XE7:
C:\Program Files (x86)\Embarcadero\Studio\15.0\source\data\datasnap\proxygen\DSProxyGen.dproj
Note that it would not work if you have specified any Transport Filters (ie. ZLibCompression,PC1,RSA etc.), returning errors for example "TDBXError: ZLibCompression Filter not found."
A temp workaround I've used during development time is to add another TDSTCPServerTransport comp that does not have any Transport Filters and then DSProxyGen works fine.
See the unit DSProxyDesigner.dcu (for which the source file is not included, but should be at database\external\src\pas\datasnap\proxy\DSProxyDesigner.pas). This is the unit used at design-time to generate the proxy client classes. I'm not sure DSProxyGen.exe is actually used, and it's a shame there is no documentation on its command-line parameters, yet...

Resources