I hope this doesn't fall into the non question category.
I would like to host a powershell environment inside my ASP.NET application, running in the same process as the Application Pool, and be able to remotely connect to the hosted environment. I already have a dll with my custom Cmdlets that I would also like to use inside my hosted session.
Note that I'm not just looking to run arbitrary commands inside ASP.NET. Instead, I want to have a full shell like interface where I can work in.
I've looked at fan-in and creating/pooling Runspaces, but this is too vague and I can't seem to find good information on this specific scenario. So any pointers would be really helpful.
Take a look at PowerShellASP - part of the product suite listed at http://www.powershellinside.com. That should allow you to host PowerShell with ASP.NET. Another option (if you want to mix ASP.NET and PowerShell in the same page) would be the PowerShell Panel:
http://www.powershellinside.com/powershell/panel/
Related
I have a basic webforms asp.net site. Currently its working on pre-created sql tables and I have to manually triger it to update data. Moving towards a live deployment though, I'd like to make it more comfortable.
How would I make it so that whenever the server software loads it up, the first thing it does before accepting any requests is to run an initialization sub? Just so I can make sure all the tables are there and if not I would create them etc.
Also, I'd like to run another sub that would trigger the data update periodically every few hours. I was thinking that if I could get my initialization sub, I could just spawn a background thread to deal with that but if theres a built-in option, I'll take it.
whenever the server software loads it up
In asp.net, you have the global.asax file - open the code behind for that and look at the possible overrides. Among them will be:
protected void Application_Start()
This always runs when the application starts up and you could use this to check the DB.
If you're in an "in-house" environment where there's a single live database server and a single live application server, then it should be ok to assume that the database is deployed before the application and you won't need this. If you're providing an application to a third-party or providing it on the web, then this is a good place to check. How you generate the DB is up to you, but checking here is a good idea. You could also have a (hidden) admin page on your site that checks the database connection etc.
trigger the data update periodically
This won't be built-in to asp.net as asp.net waits for requests and responds to them. There are ways around this, but generally triggered externally to the application. The easiest is a simple windows scheduled task that hits a page to trigger the check.
This is what's referred to as "deployment".
If your web site is deployed via MSI, this step should be done in MSI.
If your web site is deployed via Visual Studio "publish" option, this is where you need to create tables.
Some applications indeed do as you say, e.g.: create SQL tables on the 1st run. The problem with this approach is that your app will need sa rights, instead or simple read/write. This could lead to security issues.
Code which runs on web site launch (which is where initialization belongs to) is located in global.asax in:
protected void Application_Start()
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.
I am using VS2010, and I understand that when I publish a web application, the Web.config I am using is transformed based on the build settings.
i.e. When I choose Debug, it uses my development SQL server, and when I choose Release, it uses my production SQL server.
What I want to know is: Can I, using only the built in Visual Studio Development Server, select "Release" from the Configuration drop-down, and then the green "Continue" arrow (F5), and run using the transformed Web.config settings?
I would be quite happy having another file such as "generic.config" (or better: "Web.Generic.config"), which holds the master code if necessary.
I don't believe there's a simple way to do this. I would have thought it's unusual to want to run code locally against a production database, but maybe you're not in Enterprise Land which is probably what this functionality was designed for.
An alternative would be to publish your site to a server, and then use Remote Debugging to step into the code.
The plain web.config is your local and generic settings combined. The transforms tweak the generic data to match the environment you're deploying to.
There's a handy site if you just want to quickly test the results of a web.config transform: http://webconfigtransformationtester.apphb.com
I am running an asp.net application (VS2008/.net 3.5) and when running it under VS in debug more it works fine.
It reads files and directories from a network share happily.
I can run "cleartool startview [dynamic view name]" ok, I can "cleartool mount [vob]" happily.
But if I try to test for the existance of a file within the vob it can't see it.
So I tried something different, I now run "cleartool ls -short -vob_only [filename]" to test for existance.
For both of those it works fine running under VS2008 but won't work when running under IIS post deployment.
I have the set and the user has valid access to ClearCase.
Any ideas?
If you use the built-in webserver (Cassini) during development the webserver is running as you and have access to your networked drives etc. IIS on the other hand uses a different user account and doesn't share your user profile including your ClearCase views etc. That may explain your problems.
I found the problem and a resolution to this. The problem is that ClearCase is using the process user for authentication whereas the shared drive access mentioned in the original question is using the thread user.
The reason for this is the when accessing ClearCase it spawns off a new process - and child processes always use the parents process security context and not the current thread's.
The way around this was to run the web application within its own application pool which is running as a user with rights to access ClearCase. An inflation of rights beyond what should be really necessary however it did the trick.
As part of my overall development practices review I'm looking at how best to streamline and automate our ASP.net web development practices.
At the moment, our process goes something like this:
Designer builds frontend as static HTML/CSS on a network share. This gets tweaked until signed off. (e.g. http://myserver/acmesite_design)
Once signed off, developer takes over and copies over frontend HTML/CSS to a new directory on the same server (e.g. http://myserver/acmesite_development)
Multiple developers work on local copy until project is complete.
Developer publishes code to an external publicly accessible server for a client to review/signoff.
Edits made locally based on feedback.
Republish to external server.
Signoff
Developer publishes to live public server
What goes wrong? Lots of things!
Version Control — this is obviously a must and is being introduced
Configuration errors — many many times, there are environment specific paths and variables (such as DB names, image upload directories, web server paths etc. etc.) which incorrectly get copied from local to staging to live etc. etc. with very embarrassing results.
I'm pretty confident I've got no.1 under control. What about configuration management? Does anyone have any advice as to how best to manage an applications structure within asp.net apps to minimize these kinds of problems?
I found that using SVN, NAnt and NUnit with Cruise Control.net solves a lot of the issues you describe. I think it works well for small groups and it's all free. Just need to learn how to use them.
CruiseControl.net helps you put together builds and continuous integration.
Use NAnt or MSBuild to do different environment builds (DEV, TEST, PROD, etc).
http://confluence.public.thoughtworks.org/display/CCNET/Welcome+to+CruiseControl.NET
You got the most important part right. Use version control. Subversion is a good choice.
I usually store configuration along with the site; i.e. when coding a PHP-based site I have a file named config.php-dist. If you want the site to work at all you'll have to copy + edit in all the required parameters (this avoids storing passwords in version control). The -dist file should have reasonable defaults.
Upload directories should be relative if possible; actually all directories should be relative. I'm not experienced in ASP.net, but if it's anything like PHP the current directory is always the directory of the file being requested. If you channel all requests through a single file (i.e. index.asp), then this can even be found programmatically. Or you could find it programmatically by using the equivalent of dirname(____FILE____) in your configuration file.
I also recommend installing IIS (or whatever webserver you are using) on all development workstations (including the designers). Makes life easier as noone can step on each others toes. What one has to do is simply add test hosts to the hosts file (\windows\system32\drivers\etc\hosts iirc) in addition to adding a site to the local IIS. This plays well with version control (checkout, add site to IIS and hosts-file, edit edit edit commit).
One thing that really helps is making sure you keep your paths relative where you can and centralise them where you can't, so when I've been working with ASP.Net I have tended to use web.config to store any configuration and path related data that can't be found programmatically. It is quite possible to find information like your current application path programmatically through the Request object - it's worth looking in some detail over what the environment makes available to you.
One way to make sure you don't end up on something that is dependent on the path name is having a continuous integration server executing your test suite against your application. Each time this happens you create a random filepath. As soon as someone introduces a dependency on the filepath it will fail.