Is it possible to Edit and Continue in ASP.NET MVC 3 app using Visual Studio 2010? If so, how can I do that?
btw, my OS platform is x86.
Edit: when I hit f5 and then try to edit the code I receive the following error: Changes are not allowed while code is running or if the option 'Break all processes when one process breaks' is disabled. The option can be enabled in Tools, Options, Debugging.
Even though the option is enabled I cannot edit my code when code is running.
After a lot of messing about, googling, and (essentially) guess work, (I am actually running x64 environment) I found that the following enabled MVC 3 edit and continue for me Great !
Setting all the projects to x86 in configuration manager
Setting my WebApp project output path to "bin" in the properties window
Setting my WebApp project to use Visual Studio Development Server
(project properties > Web tab)
following the 2 simple instructions from Pro ASP.NET MVC 3
Framework, Third Edition
Now I can set a break point, then hit F5, then when the break point hits - I can change my code (e.g. in controllers or class library projects referenced by the MVC web app), and continue debugging (F5 again) and the changes are picked up, and everything seems to be as it should !
Further to this, you'll find that Edit and Continue will not work on certain methods -- those with dynamically-typed variables and those with lambda expressions. You'll probably have a lot of lambda if you're using LINQ to (anything) to retrieve data from repositories, and of course ViewBag is a common dynamic in MVC applications.
So, Edit and Continue and MVC mix poorly. Which is all right, really, because it gets you into the habit of test-driven development -- write good tests, code to pass the tests, and only then build and run.
Related
Whelp, I avoided it as long as possible, but the time has finally come to make some changes to some ancient VB6 code. I'm a recent college grad so I was hoping to stay away from this code that is almost as old as I am.
The DLL is compiled in a local installation of VB6 and deployed via Component Services. That component is then called by VBScript in a Classic ASP application running on a windows 2003 Server.
I've tried just about everything to debug this code using the VB6 debugger, but I can't get it to work. I've compiled the DLL to the same location that Component Services has it deployed to (a random folder on a non-system drive), and set binary compatibility to that same DLL. Each class file has instancing set to MultiUse and MTSTransactionMode set to '1 - NoTransactions.' The component works fine until I attach the debugger, then I get 'ActiveX component can't create object' when trying to instantiate the object. If I detach the debugger, it works again.
I noticed that in Component Services when I attach the debugger, the DLL location changes to C:\Program Files\Microsoft Visual Studio\VB98\VB6DEBUG.DLL, which I assume is just VB6 intercepting calls to the component. When I detach the debugger, it changes back. I should also note that the component is configured to use a specific user identity separate from my logged-in user account, however everyone has been granted access to the component via a user role. The component activation type is also 'Server Application,' however setting it to 'Library Activate' doesn't seem to make a difference.
I've also tried using the VC++6 IDE, and VS2010, but had no luck. I was able to debug the dllhost.exe in VS2010 and was able to hit some breakpoints, but the symbols weren't loaded properly. I tried compiling the DLL with debugging symbols and loading those to the VS2010 environment via the Debug settings menu, however that didn't resolve the issue.
I also didn't find the component services JIT Debugger to be very useful. I'd much prefer to just be able to debug in VB6.
What amazes me most is that this code is thousands of lines and has been maintained without the use of any debugger whatsoever. My young, spoiled self isn't ready to accept that this code can't be debugged.
Good afternoon, everyone.
I'm running Xamarin Studio (Mac OS) and I need to deploy a Web Service in order to build a safe communication with a MySql Database which my Xamarin.Forms app depends on
So far I've opened a new solution and added a new "Web Service with CodeBehind" from the ASP.NET Web Forms palette.
Now I have all template stuff: a DataWebService.asmx with a single line and a DataWebService.asmx.cs with an empty class inheriting from System.Web.Services.WebService.
Now, all I want is to learn how to deploy this Web Service so it can be imported by my other App and consumed.
(I do have a domain to deploy it to, but I won't mind localhost)
In order to make things as simple as possible, a HelloWorld application will do just fine.
----- Extra comments:
I suppose this is pretty much everything I'd have to do in Visual Studio, but I'm avoiding the need of another machine - even a virtual one, once I don't have a Windows license.
It seems to me that a wizard should be able to do the rest, but apparently there isn't such a thing in Xamarin Studio (which I'm hoping to be wrong)
The CodeBehindService.asmx.cs lacks the [WebService] directive I've seen on my research so far, which makes me think Xamarin Studio is still incomplete and can't support me in this task
I don't mind doing some work myself, though I'm not sure of what would be needed. My priority is: deploy
What I have: an almost empty asmx file; a dll binary
What do I do with it?
I tried simply uploading them but the "Add Web Reference" wizard asked for a discovery file; as you can see I lack the basics.
Is there a way to precompile the ASP.NET MVC views on an Azure Web App (specifically when published via Release Management on VSTS)?
Once each view has been hit once, the page subsequently renders very quickly. But that first delay can be a doozy for users and there's no way to script touching each page.
I'm not sure if I need to change something in the build/release processes on VSTS (I am using the Visual Studio Build build step and the Azure Web App release task) or if I need to run something on the Azure Web App instance after it is released (or something else altogether).
It seems like finding some way to call aspnet_compiler after publish might be what I need (and I have seen that in reference to Web Roles on Cloud Services) but I can't get that to work.
Calling
%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler -v "/" -p "d:\home\site\wwwroot"
via the Console in the Azure Portal executes just fine (and finds errors if there are any) but doesn't have any impact on startup time - hitting a view the first time still takes a long time.
So maybe that isn't the right direction.
I've looked at RazorGenerator (including the .MSBuild nuget package) and I couldn't quite get it to work, but really I was hesitant to make so many changes to the projects just to get precompilation on release.
Also note that I am currently using TFVC, not Git, in VSTS, so the Kudu/Git integration (that does seem to trigger the precompilation according to some articles) isn't available to me as far as I can tell.
Other ideas?
You can add "/p:PrecompileBeforePublish=true" argument in "Visual Studio Build" step:
Then the task will call aspnet_compiler during the build process and generate a precompiled output for deployment.
In visual studio 2013+, choose Build->Profiles. Select the profile, then choose "Settings". Underneath "Configuration", expand "File Publish Options", and then check the "Precompile during publishing" option.
I was hoping to get some people's expertise as I'm currently outside my main domain. I'm currently working for a client that has an old system written in VB6 COM Objects. They use these to do basic Database interaction. These COM Objects are used in a Classic ASP website.
I've been tasked with getting the site up, running and in a build-able environment (Windows 8.1 is what they want to use).
I've been working through all the blockers associated with this and I believe I have it in a running state (as in I've configured IIS and been able to run the website, log in and click around and so far nothing has crashed).
I can make changes to the code in Visual Studio 6 Enterprise and those changes are working so I'm confident I've got that about 90% of the way there.
I've now got 2 problems both somewhat related:
Problem 1:
Problem 1 is now debugging, both the ASP & the VB code.
I can put a break point in the VB code and 'Step-Into' it (to attach) and then run the site and the code that runs in the global.asa file gets run and hits that breakpoint no worries, can step through as I would expect.
The problem then comes when I go to 'login' to the system. I use the same user/password that works if I'm not 'attached' the system crashes with a "An unhandled exception ('Error in loading DLL') occurred in w3wp.exe [3284]." - If i try to load up a debugger from this Visual Studio 6 is not an option in the list. If I then detach and I can do everything as before.
Does anyone know what could be causing this? Or have another way to be able to debug/step through this?
Problem 2:
They had previously been 'running' the website through Visual InterDev 6.0 - they could add breakpoints to the Classic ASP code and be able to step through then into the VB components.
The problem is that although I can install InterDev on my machine, I can't actually set it up. It appears to need FrontPage Server Extensions which although they can be 'installed' on IIS 8.5 they don't seem to be officially supported by Microsoft. So I've managed to install it without any issues but it doesn't seem to be configured in the same way that InterDev needs it to be able to setup a solution file/run from it.
My Question is this: Has anyone been able to configure FrontPage Server Extensions in a way that InterDev works?
OR is there any other tools I could use to 'run' a Classic ASP site that would allow me to debug it properly.
Let me know if you need any more information.
Thanks in Advance,
Michael
I think you actually don´t need Interdev in order to debug the classic ASP code. Just create a blank solution in Visual Studio and add all the classic ASP files from the virtual directory (editor and debugging capabilities for classic ASP files are still supported, even in the latest version of Visual Studio).
I assume you run the web application in your local IIS... once you have the solution, open the script of interest, put some breakpoints and than attach the Visual Studio debugger to the web server´s worker process (which should be w3wp.exe). Maybe you need to manually select the Script code type (automatic code type detection might not work).
Currently, I'm maintaining an older ASP.NET website. In the solution, there exists 5 C# projects which build to assemblies as well as the development server's web directory. Normally, I do whatever work needs to be done (adding pages, making changes to existing projects, etc), build the projects (the current output path is my development server's wwwroot\bin\ directory) and if all is well, I open Windows Explorer and drag either .aspx or .dll files from the dev server to the production server. It's that last step that I'm wondering if there is a better way of doing. Does anyone have a different way of doing things where you don't have to leave Visual Studio to push updates?
You should add a Web Deployment Project, that´s (in my opinion) the easiest/best way to deploy a Asp.net app
Here´s an interesting article from the MSDN Magazine. http://msdn.microsoft.com/en-us/magazine/cc163448.aspx
ASP.NET Web Site Precompilation Overview would seem to be what you are wanting, yes?
Otherwise, there are web deployment projects for VS 2005 and web deployment projects for VS 2008 if you want a couple of alternatives depending on which version of Visual Studio you use.
How old is older? Are you using ASP.Net 1.0, 1.1, or 2.0, as those are what I'd consider older, but then I've been doing web development for over a decade.
You might want to consider creating a build script and a deployment script. You can look at using either Nant or MS Build, which are popular, or simply go with a batch file approach.
Some of the reasons I suggest going with scripts are:
1. You'll never forget to push that one file that you added
2. Either your build script or your deploy script should create a copy of all the artifacts need for deployment. This way, if you push out a bad build and need to roll back for whatever reason, guess what, you have a working copy tucked away somewhere.
3. Your scripts can run the installers (if you created a setup project) or they can simply copy out the files to the correct location, so that you don't have to have your dev box pointing to the right folder.
4. Sometimes you need to make changes to the configuration before you deploy... your scripts can also do this for you.
In general automating the whole process just makes it easier, faster and repeatable.