Run a remote python script from ASP.Net - asp.net

I have a python script on a linux server that I can SSH into and I want to run the script on the linux server( and pass it parameters entered by the user) and get the output on an ASP.net webpage running on IIS. How would I be able to do that?
Would it be easier if I was running a wamp server?
Edit: The servers are in the same internal intranet.

Probably the best approach is the least coupled one. If you can determine a protocol that you're comfortable with the two (asp/python) talking in, it will go a long way to reducing headaches.
Let's say you pick XML.
Setup the python script to run as a WSGI application with either cherrypy or apache (or whatever). The script formats it's response in XML and passes that to WSGI which returns the XML over HTTP.
On the ASP.NET side of things, whenever you want to "run the script" you simply query the URL with the WebRequest class, then parse the results with LINQ-to-XML (which on a side note is a really cool technology).
Here's where this becomes relevant: Later on if either the ASP.NET implementation or the python implementation changes you don't have to re-code/refactor the other. Later if you realize that the ASP.NET app and some desktop app need to be able to do that, you've standardized on a protocol and implementing it should be easy and well supported.

Related

Run Batch File in Asp.net C#

I am using asp.net C# 4.0
I have a batch which will open a text file.
Batch File query
ECHO OFF
start D:\accounts\request\08__processing\0377e792-4ca9-4550-b78c-de2bdf26611f.txt
ASp.net Code
System.Diagnostics.Process.Start("D:\\bacthFile.bat");
when i double click on the batch file its opening the text file.But when run above code its not opening any notepad.
it is not showing any exception also.
Please Help
Thanks
This is the wrong way to read a text file from ASP.NET, you need to use System.IO and put files you need to read somewhere where ASP.NET can get at them, eg.. App_data. That said, here is how to do it the wrong way: IIS runs on an invisible virtual window--it's a service. There is a way to get some services to display the UI, I forget how. In any case, you'd have to RDP onto the server, to see such a window after starting the service and goosing it into displaying a UI (this trick might not even work for IIS).
Next, as commenters noted, on IIS, you'll have one set of credentials different from your own (depends on what version of IIS)-- in any case, it will have restricted access and be somewhat sandboxed. If you set up impersonation and windows authentication in the web.config, sometimes you can get your request to run with your credentials.
Next, if the web host runs in medium trust, you might not be able to launch arbitrary apps from the asp.net appdomain.
Finally, the only way this could ever work is if your app is always running locally with casinni (the visual studio development server)-- but in that case, you could simplify things a lot by using a console app instead of asp.net unless you really need the HTML templating, say for output.

Connect to SQL and display results in HTML from distributable package

I must apologise for the vagueness of this question, but I actually no idea of where my starting point should be here.
Among others, I know SQL & HTML/PHP/Javascript
I want to create a program that I can distribute amongst some peers which connects to a user-specified SQL server and generates a set of fixed reports. And I want my code (or a least the SQL) to be complied/hidden. I want this program to run on any Win 7+ client regardless of access to a local IIS or other server.
How I create an exe or other that runs a mini web server of sorts so that I can use PHP or even ASP/VB to connect to a SQL Server and display HTML reports in a web browser.
I know how to write what I need to access the server and build/display the reports, but I have no idea of where to start to make this work on a client machine without a webserver.
Any starting points to investigate will help me greatly.

Deploying an ASP.NET web site to a remote VPS with Jenkins

I am just starting to get my head wrapped around continuous deployment with Jenkins, but I am running into some roadblocks and I haven't really found very many good, definitive resources on the topic in regards to ASP.NET applications.
I have set up a local build server than successfully pulls down code from a SVN repo, and builds it OK with MSBuild. This works well so far, but now I'd like to automate pushing this compiled code to a development server.
My problem is this - from what I gather based on what I read (which may be an incorrect assumption...) is that the staging server is typically within the same network as the build server, meaning you can share network resources, servers, etc.
In my case, I want to run the Jenkins server on a remote VPS, then deploy to other remote VPSes (so, essentially individual isolated machines communicating with each other).
I have seen alot of terms, but I am very new in my Sys Admin / DevOps type skills.
So, my question is this:
Is it even possible to, using Jenkins on a VPS, to then deploy to any particular server I choose? (I have full access to all of them, so if its a security thing, I can fix that... but they are not within the same network/domain)
What is the method to achieve this? I've seen xcopy, Web Deployment Packages (msdeploy), batch scripts, etc. mentioned, but not really a guidance behind what to use in what situations. Are any of these methods useful to achieve my goal?
Thanks for any help or guidance!
How is your Powershell? ;) You should check out psake.
psake is a build automation tool written in PowerShell. It avoids the
angle-bracket tax associated with executable XML by leveraging the
PowerShell syntax in your build scripts. psake has a syntax inspired
by rake (aka make in Ruby) and bake (aka make in Boo), but is easier
to script because it leverages your existent command-line knowledge.
psake is pronounced sake – as in Japanese rice wine. It does NOT rhyme
with make, bake, or rake.
You can deploy your files to the target server through SSH. Jenkins do support transfers through SSH. All you need to do is setting up a SSH server ex : CopSSH and a user account with admin permissions. and configuring the Jenkins to transfer through SSH.
Create host configurations in the main Jenkins configuration
Add an SSH Server
Add the public key to the remote server (the build server)
Click "Test Configuration"
Save
Configure a job to Publish Over SSH (Post Build Action)
Add Transfer Set.
Refer Publish Over SSH For More details

Using Curl to Automate Upload Files to ASP.NET Application

I am trying to use cURL to automate some deployment tasks to an ASP.NET Application. But I am having some problems with it. The login part works perfectly but i guess the application for some reason has some sort of control for this kind of tools. These application was developed or an external company(real crappy app). Basically what i need to do is upload every month like 10 xml files by hand which is stupid!. I want to be able to automate this by using my own script(like ruby) and call cURL on the background to process the http requests.
Does any one know about any problems using cURL and an ASP.NET app?. May be should I write my own C# tool for this?.
Any ideas?
There's no problem with curl and ASP.NET. curl speaks HTTP and offers many different features and ways to send data, including multiport formpost uploads etc. You most likely just haven't figured out exactly how to mimic a browser when doing your command lines.

Is there a good way to create a recurring import for an ASP.NET site?

The site I'm working on is running Windows Server 2003 and SQL Server 8 (2000?), and ASP.NET 3.5.
I need to have some sort of script or application run to import data from an FTP'd text file, into the database. There is already a site running on the machine, that uses the current database. Can I use a scheduled task to reliably kick off some sort of .aspx page that will import the data? Or is there a better approach?
What about making sure that no one else can access the page that runs the import? I don't want random users running the import!
Thanks in advance!
P.S. some processing needs to occur on the data before its inserted. i.e. lookups, conditionals, etc, so the DB tools aren't robust enough (I think). I hate DTS, and I SSIS is not available in this version I think.
If you want to have a C# App handle your import I would suggest a windows application (exe) w/o a form (better than a console app because it does not pop up any UI whenever it runs). Have it run every so often (every minute) by a scheduled task.
Why would you use ASP.NET? Depending on the complexity of the job you could either load it directly to the database (BULK LOAD) or use DTS (SQL Server 2000) or SSIS (SQL Server 2005/2008) if more complex processing is needed.
DTS and stored procedures in a job.
BCP and stored procedures in a job.
You say you need to do alot of lookups and conversions? SQL is good at that - and good at doing it fast. It can seem a little intimidating at first, but it's not hard.
run a BULK INSERT or bcp to import the data instead, see here http://msdn.microsoft.com/en-us/library/aa173839(SQL.80).aspx
I'll echo other people here - you don't want to have a scheduled task hit a web page. SQL Server provides some good data import options, or you could just write a simple windows program and run it as a scheduled task.
Another option would be to write a windows service that watches your FTP directory and does the import.
As others have said, probably a separate console application (triggered by a scheduled task) or a windows service would be the best option for this scenario.
On the other hand, if you already have all the required functionality available in the web app running on the server, then you could probably set up a scheduled task, that starts a script (VBscript, JScript), which in turn calls a page of the web app.
To have some sort of security (e.g. preventing that any user can call that page), you could add some code to the page, that checks if the page was called with http://localhost. This would at least prevent the page from being called from a remote client.

Resources