I am new to ASP.NET and trying to get the debug feature working so I can see the values from the variables in the code. I know that I have done it all wrong from the beginning so the debug is not working properly now. Here is what I did.
A while ago, I played around and built a number of ASP.NET pages, kind of manually creating the .ASPX page and then the code behind page .ASPX.VB directly from the web server. Everything is working fine. I have my desktop computer connected to the Web server, and mapped the directory contains all the web pages (including both classic ASP and ASP.NET), where I just right-click on the web page file and edit directly.
Now, I am updating some ASP.NET pages, and want to learn how to perform debug, but getting many errors when I put the breakpoint and run Debug. Example of errors like "AjaxControlToolKit.Dll not found". Note that the page is still working fine if I view it from the browser, so the AjaxControlToolKit is there.
Can you please suggest the correct way that I should do to retain all the ASP.NET pages and also make the Debug feature working correctly? I have no problem to migrate all web pages from the web server to my local drive (desktop) if that requires for the Debug to work properly.
Thanks in advance,
Frankly you've got an uphill battle ahead of you - it's probably not debugging because the <assembly name>.pdb files are not in the BIN folder of your website, or if they are they are out of date (compared with the source files) or point to the wrong location (of the source files).
IMHO I think you should create a fresh web project in VS and then recreate each page in VS and copy the appropriate code. I think that would be quicker and less risky. The road you're currently heading down will take you on a tour of debugging which would be useful, but not necessary at this point in your learning.
Typically most people develop locally in VS and then use the Publish function (in VS) to create a folder you can then upload (manually if need be) to the remote server.
Usually you want to avoid debugging on the production server unless there's a problem specific to it, which isn't present locally.
Related
Right now I'm working in a software developed by another programmer who it's no longer part of the project anymore, he send the complete source code of the project.
The thing is, that in some points he make calls to asp pages whithout the extension '.aspx', and this work perfectly fine on the server (Virutal Machine on AWS with Windows Server 2019 and IIS 10), but on my local machine, it gaves me an 404 error, everytime that finds this kind of redirects whithout the properly extension.
Login1.DestinationPageUrl = "./CPersonalRegister" <--- this works perfectly fine on the server, but not on my local machine.
I dont know what other configuration i could search for, or if it's somethind wrong with the IIS.
The used .net framework is 4.0
Most sites (at lest for a very long time) have what is called Friendly URL's turned on.
This means that URL's look a lot nicer, and you don't have to include the .aspx extension for each page you navigate to.
Probably the most easy way to setup this to to nuget the package "friendly" url's.
This one - even for a asp.net webforms site should work:
So, starting from vs2010, "friendly" URLS should have been installed for your given project.
but, give the above a try. (make a backup copy before you do this, since it sounds like you not heard of this "basic" and "often" used feature of asp.net sites for the last 13+ years).
There is also a step by step floating around on how you can add the bits and parts manually, but nuget package above should do the trick for you.
I am a C# winforms programmer, not used to ASP.Net.
As a winforms programmer I build regularly to detect syntax errors.
Recently I opened a Kentico website in Visual Studio and to my surprise found that there were build errors.
Does this matter?
My instinct is to go about correcting the site until it builds. This is a side track from what I set out to do.
If you are attempting to build any kind of quality into your project/software, then yes, it does matter if it builds.
Regarding Kentico and build times, if you're using a website vs. a web project, yes the build times are typically longer and range anywhere from a few minutes to I've seen upwards of an hour. The build times depend greatly on the machine building it as well. So if your machine has a Celeron processor, with 1GB of RAM and a 5400 RPM drive, you're going to take longer to build than a machine with an i7 processor, 16GB of RAM and a solid state hard drive that can read/write 500+ MB/s. Also keep in mind Kentico out of the box has over 9000 system files in it so as a website, it will take some time to build.
One of the first things I check when a site doesn't build is to ensure all the referenced DLLs are in the website/project. If not, this will cause several errors and is usually a very simple fix. If you have any kind of errors from code which resides in the /App_Code directory, your site will NOT run at all when you publish it. If you have errors within any other directory, the site will run BUT wherever those code files are referenced on the website, will display errors. So in your instance if you have webpart files in the /CMSWebparts/OurCompany folder, if those webparts are placed on pages within the website, those pages will error out even though the rest of the site is running.
In my opinion, just fix the errors and be done with them. Then check the code into a version control system to keep track of the changes.
Does this matter?
It depends on what you are trying to achieve with your website. If you want to make it available to the public then building is definitely something you should consider as top priority. If on the other hand you want to have the source code open in Visual Studio on your local machine, just for reading purposes, then building is not necessary.
I'm working on a fairly large ASP.NET web application and I'm taking a big productivity hit when I do work in the interface. I can zip through adding features to the database and API, then I hit the interface and having to recompile and run eats up a lot of my day.
For example if i'm working on a tricky bit that isn't behaving quite right and requires a number of tweaks I'll have to go through multiple [stop/tweak/build/run/log in/navigate back to page] cycles, which really kills my flow and has me staring at the screen with my finger hovering over the hackernews bookmark each time.
I've been fiddling with ways to get around this problem but I haven't improved my situation much. Here's what I've found so far:
visual studio will restart the app frequently when you change static files (js/css/etc), which shouldn't require a restart. If you run VS with IIS express instead this problem goes away.
If I know I have a bunch of messing around to do i'll cut/paste my code into a server script tag on the markup page, run the product, and tweak until it's good, then cut/paste it back. This is annoying because it often requires setting up a number of Imports page declarations and code editing features in ASP.NET files, while better than ever in VS2010, is not as good as in C# files. Plus, it still restarts the app occasionally once enough changes are made.
I can exclude the codebehind file from the web application project, change the "codebehind" attribute in the aspx page declaration to an "src" attribute, then edit the code from there while the app runs (until i make enough changes to trigger a restart.) However now intellisense doesn't work in the codebehind, among other things.
Am I missing something blindingly obvious here, or is development in ASP.NET web applications really supposed to be this slow? Thanks for any solutions you can offer.
I never run my applications through Visual Studio. Set yourself up with IIS and then configure a site to point to the location of your application along with a faux domain. Edit your hosts file to point the domain to localhost.
Then when you want to view your site, just visit the domain that you chose. If you need to modify CSS or script, just make your changes and refresh the page. If you make a code change, compile your app and then refresh the page.
If you need to actually use the Visual Studio debugger, then just attach to the IIS process (application pool name) and your breakpoints will get hit.
I've found a combination of techniques that brings my productivity up a fair bit.
Use an alternative browser like Chrome. When you stop the VS debugger and you're using IE, VS will shut down the browser, but it won't do it with Chrome (or Firefox, or anything else.)
Switched web.config to run in Windows Authentication mode and wrote a quick transparent login routine enclosed in conditional compilation tags (debug only, this feature is not perfect for our production product.)
Now when I'm getting into it I can stop the debugger (which no longer closes the browser,) make code changes, build, optionally start the debugger again, and just hit F5 in Chrome to load the latest. The refresh obviously takes longer since the app has to start up but there's no "run browser/log in/navigate back to the page" task anymore.
Hopefully this will help somebody else in a similar situation.
I have a problem debugging a web forms application that is configured to use IIS for debugging, under Windows 7 and Visual Studio 2010. An example has just occurred, where I make a change to the code behind for a web form, save, and apparently rebuild before starting the app using F5.
The app starts, and I get an error message trying to do something in the app. I tell the debugger to break when an exception is thrown and try my task again, only to be told
The source file is different from when the module was built.
where the module is C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\root\9d7b45ca\11a98b19\assembly\dl3\5e6cf0b2\636409d4_dfeecb01\PerfixEMS_Admin.DLL
The physical folder for my test web site is set to the web application project's source folder, so I have always assumed that IIS will look in the bin folder for required assemblies, and these will be rebuilt as expected. Why is this not happening?
Cleaning the solution usually works for me.
Update
Given the high number (320) of projects I understand why Clean and Build won't work for you. You should however try it at least once to see if fixes things.
If it does fix your problem but doesn't last you'll need to do one of two things.
Clean just the one file
Delete the offending temp file. You probably won't be able to do this because with VS running since it may have a lock on the DLL. You may also have to stop IIS. You can use Process Explorer to look for the processes that have a lock.
Use a custom solution
Its unlikely that you're going to be modifing all 320 projects at the same time. Create a custom solution for just the projects you're working on. You'll still be able to step through any project you have the DLL and PDB for if you need to.
Which to do
Using a custom solution has its problems since you can no longer use project reference for projects not in your solution. This impacts your team's source control. You'll also have to make sure the DLL's and PDB's from outside your solution are in a stable location and you'll need a way to detect when thoes other projects have changes that you care about.
These problems can be overcome with a careful check-in process for Project changes and scripts that copy files and working with team members to figure out how to communicate changes.
On the other hand closing VS for every change or running Clean and build isn't really tennable either.
it may be a workaround, but I just need to see if it will work or not, then we may investigate more in the original case. but for now, try this:
1- publish this website to a different folder
2- open the newly published version from your preferred browser (ex: http://localhost/APP_NAME).
3- from VS, open "Debug" menu, choose "Attach to process..."
4- select the IIS worker process "w3wp.exe" and click "Attach".
(if you can't find it, make sure that the checkbox "show processes in all sessions" is checked)
5- start debugging your source code normally and let me know what happened, thanks.
I'm fairly new to web service development, and I am really confused about how ASP.Net Development Server synchronizes with code during debug mode. When I make changes to my service, I cannot figure out how to propigate those changes so that my client can "see" them (I've been able to synchronize through a stumbling series of publishing the service, viewing the service in browser, etc... but I have a feeling there's a more reliable system than my random ritual).
Here are the symptoms I'm seeing: After I've made a change to the code behind my service (Service1.svc.cs), started the application through the debugger and attached the debugger to the WebDev.WebServer.exe process as well, my latest changes are not executed, and my breakpoints are not hit (they have the message that
"The source code is different from the original version."
What really baffles me, though, is that when the ASP.Net Development Server notification pops up in my system tray, its physical path points to my project folder, so I don't understand how it could be looking at anything but my current code files.
I do not like to play with knives but the only thing that worked for me involves editing the .csproj file itself. So, unload the project file, edit it by cutting and pasting the three asp.net files so that they are together in the ItemGroup. However, sometimes it is necessary to go further as explained here: http://carnotaurus.tumblr.com/post/4130422114/visual-studio-debugging-issue-with-files-of-the-same - Also, I give a list of other proposed solutions that did not work for me. I hope it helps.