Enable Script Debugging in Classic ASP / MVC3 hybrid application - visual-studio-2010

I have a site that is a .Net MVC 3 / Classic ASP hybrid. We have this as we are steadily replacing the Classic ASP bits with .Net.
Currently when I hit F5 in VS2010 the site spins up and runs fine. However, I don't seem to be able to set break points in the Classic ASP code. How can I do this in IIS Express?

As far as I know ilive, you cannot debug classic the same way as you would, say with vb.net or c# because classic asp is not compiled. Therefore an executable is not created and loaded for you to be able to actually use say intellisense.
WIsh it would though. How about moving to vb.net, its so much better!

You can debug classic ASP the same way as .NET.
You will have to enable server-side debugging in IIS. The location differs depending on what version of IIS you have, but in IIS7 you can doubleclick the ASP icon in IIS manager for your website (or for all websites) and enable client-side and server-side debugging.
As long as you develop on the same machine as IIS is running, errors will be caught and you will get a choice of possible debuggers, including your installed visual studio software.
You can add breakpoints and watches as needed.
There is even a vbscript keyword "stop" you can use in your classic ASP code to get a breakpoint and start the debugger.

I put together this ASP include class which works with Firebug+FirePHP. It allows you to log values (including strings, multi-dimensional arrays and even objects created with json.asp) to the firebug console and view ASP's built in collection objects which can help (particularly with Ajax where you can't output debug data without breaking the json response.) Ajax script load times and errors are automatically logged for quick viewing.
https://github.com/dmeagor/ClassicASP-FirePHP
Just include the file and use log(somevalue) to send formatted variables to the firebug console.
Released under MIT open source license

Related

Integrating MVC3 into an existing Classic ASP application

We have a very large application written in classic ASP. The application consists of a single codebase which is accessed by multiple tenants, each of which has their own database. The application has been developed over a number of years.
Initially we were going to write a new application in MVC3 which would take over from this application, and eventually migrate customers to this new application.
We are now wondering if it is viable to add to the existing application gradually using code written in MVC3. At some point, we would expect the whole application to be running in MVC3 with no classic ASP left. The application would have to act as a single application, with one login giving access to the existing classic asp parts of the system as well as the new parts written in MVC3.
Does anyone have experience of doing this? What issues are we likely to face? Are there any pitfalls we should look out for?
I am in the process of completing a (painful and long) migration from a Classic ASP site to MVC3.
I looked at running both side-by-side in detail because this is a large ecommerce website I have migrated and it would have been beneficial.
The issues I came across and which eventually led me to abandon this option are as follows:
If you have URL rewriting on your Classic ASP website then it is
likely going to interfere with ASP.NET MVC routing
Authentication is going to be very difficult because of the way
authCookies are set in both technologies
In my case both of these points were show-stoppers.
Saying that, there have been some interesting developments in the open source arena since I started that try to tackle the issue of migrating Classic ASP sites to MVC.
Specifically, you might want to take a look at the ASP Classic Compiler on codeplex. It looks promising.

Is webmatrix appropriate for a "private" web app?

I would like to build a web interface for an app I build for a client. The app itself is made with Access for the front-end, and SQL Server for the database.
The idea is to allow them to check the stock of an item, or see the orders of a client using a laptop or even a smartphone, while on the road.
I have a basic experience with html and CSS, since I made a few simple sites.
My question is: would webmatrix be a good choice for that job ?
Since I master VBA and SQL quite well, and the client is a MS environment anyway, I thought webmatrix could be an easy path for that project.
Any feedback appreciated. Other suggestions are welcome. Thanks.
We have a very similar environment. We have a legacy application developed in Microsoft Access running against SQL Server 2005. Initially we developed a single page website using WebMatrix that had some key data displayed on it. Over time, it's grown to having maybe 30 pages, with both employees and customers logging in to it. It's my plan to gradually replace the Access application completely with a WebMatrix application.
Generally, the WebMatrix development enviromnent is quite competent for simple pages and I like its lightweight quick-to-boot easy-to-use approach. On some of the more complicated pages that use c# classes, I will switch to Visual Studio.
Since you have some experience with HTML and CSS, then I think the razor syntax that WebMatrix uses is a natural progression. If your only language experience has been vba, you might have some challenge using c# or perhaps vb.net. I would recommend c# as being more of an standard.
Good luck!

excel, mysql (with authentication)

We are creating an excel plugin but need some guidance as we're new to excel development (but not new to programming).
Here's what we want: Once the user installs the plugin, they will authenticate w/ our server to ensure they are a subscriber to our service (the plugin will save login info and password so they don't have to enter credentials everytime). From there, the user will be able to type in custom formulas (UDFs) in Excel and pull data from our mysql database.
Here's what we've tried:
We started w/ VisualStudio (C#) and got excel to output some mysql data when the spreadsheet starts up. Looking into it further, people have suggested to use ExcelDNA to create UDF's. So, we did some reading on ExcelDNA and have created a helloworld xll but haven't been able to find anything on how to authenticate the user. Should we be using ExcelDNA? VisualStudio? Something entirely different? thx!
Excel-DNA is exactly right library to use (I'm the developer, but still...).
You would probably use Visual Studio as your IDE to make the .NET assembly with functions and macros in. But your .NET .dll will be integrated into Excel using the Excel-DNA .xll instead of the Visual Studio Tools for Office (VSTO) libraries that ship with Visual Studio Professional.
Nothing in Excel-DNA (or any of the other add-in frameworks I know of) gives you a pre-built implementation of the authentication feature you ask for. But implementing it yourself should not be too hard - you'd do your check and possible username/password prompt in the AutoOpen handler of the add-in, and enable or disable the functionality based on the result from your web call. You should be a little bit careful if you are making a potentially slow web request during the add-in load...
You could also implement the log-in via ribbon interface, with an indicator of the current status and a button to log in. That way users would not be confused about why your add-in 'is not working' when the functions are disabled.
On the Excel-DNA CodePlex site http://exceldna.codeplex.com there are links to other projects based on Excel-DNA. The best place for support is the Google group at http://groups.google.com/group/exceldna. I also monitor the 'excel-dna' tag on StackOverflow, but often the group is nicer for ongoing back-and-forth discussions and explanations.

Windows Workflow Foundation 4 (WF4) ReHosting

I've been looking at the possibility of ReHosting a WF4 Workflow to be used to debug running Workflows. All the posts and samples I've seen regarding WF4 Rehosting are using a WPF application to initially Host the Workflow, and then use the WorkflowDesigner in ReHosting it. Is there any way to Rehost a Workflow that was hosted in a non WPF application, like ASP.Net MVC?
The WorkflowDesigner is basically a big WPF control so you cannot host it in an ASP.NET application. Neither can you in a Silverlight application. If you need to expose the designer over an internet app you would have to either create your own designer or use something like terminal server/Citrix.
You can host the designer in the browser using a wfpbrowserapplication. Details here
I just about read in another post that WF 4 will make the hosting the designer in the application easier than it is today. I too have similar requirement that the workflow designer should be availabe to the user so that he can create his own workflows. This was reasoned in that post to the fact that the WF 4 is completely markup based and no code is involved... making it easier to host in the application....

Can ASP.NET AJAX partial rendering work inside a SharePoint 2007 application page?

I have a simple page with my ScriptManager and my UpdatePanel, and my ContentTemplate has one ListBox and one Label. I am just trying to catch its OnSelectionChanged so I can update the text in the Label. No matter what settings I try to tweak, I always get a full-page postback.
Is this really not going to work, or am I just screwing this up?
You need to have Sharepoint 2007 service pack 1 -- or else there's no chance.
(Sharepoint 2007 predates ajax 1.0 -- they built some support into service pack 1)
Next, from a trouble shooting point of view, test that the exact same code functions as expected when hosted in a regular asp.net page. (Literally copy and paste your code across into a fresh page, to rule out any typographical errors). Ruling sharepoint in or out of the problem area will help narrow down the solution space.
If you have installed SharePoint 2007 (without Service Pack 1) then you can follow an example like the following article:
AjaxBasePart: Easy ASP.NET 2.0 AJAX Extensions 1.0 and Office SharePoint Server 2007
The reason for this is that there exists a specific problem with mixing doPostback, UpdatePanel and SharePoint -- and the symptom is exactly what you're seeing: a full-page postback instead of an asynchronous postback. See this KB article for a workaround: A Web Part that contains an ASP.NET AJAX 1.0 UpdatePanel control that uses the _doPostBack() ...
Otherwise you can just install Service Pack 1 to fix your problem:
Windows SharePoint Services 3.0 Service Pack 1 (SP1)
There's a specific problem with mixing doPostback, UpdatePanel and SharePoint -- and the symptom is exactly what you're seeing: a full-page postback instead of an asynchronous postback. See this KB article for a workaround: http://support.microsoft.com/kb/941955
Todd Bleeker at Mindsharp showed me a piece of code he wrote that can use Ajax on Sharepoint 2.0. It was pretty cool. I believe the company used it on their sharepoint site managment software if you want to take a look. (you used to be able to request a 30 day trial). I bet how to do it is on their yahoo group (I can't remember the name, but I am sure that if you search for mindsharp you'll find it.)
As a note, Ajax has been around for a long time. Microsoft easily supported it since 2002 maybe earlier with the release of IE 5.5 (I don't know about other browsers, I was doing internal development and we only supported ie at the time). It just wasn't called that. The term Ajax is nothing more than a marketing term that someone coined later on.
Getting the latest service pack for SharePoint 2007 will resolve your problem (and add full support for AJAX). Without the service pack you will need to follow an example like that outlined in this article:
AjaxBasePart: Easy ASP.NET 2.0 AJAX Extensions 1.0 and Office SharePoint Server 2007
Posting this hear so that people know there is an answer even without the latest service pack (secretGeek's response seems to say there is no chance).
From a technology standpoint, Service Pack 1 does not add full support for ASP.NET AJAX. You still need use the workarounds described in the various articles mentioned in the previous answers.
Particulary, you need to make sure that the web.config file for your SharePoint Web application has been updated to support the appropriate version of the ASP.NET AJAX Extentions.
The fact that the web.config had not been updated was the mostly likely cause of the problem described in the original question.

Resources