Okay, thank goodness for the free second chance Microsoft if offering on all certification tests. I have been putting off my tests. There seems to be so many other things I want to do on and for my projects other than study for cert tests. Anyways, due to Jake's break-neck speed through the tests, I thought I better get a move on.
Today I took, failed, re-took, and passed the 70-300 test. I was so bothered when I did not pass the first time that I had to immediately correct the mistake. Ordinarily, I would have waited to take this test until I had no doubt I could pass. To be honest, I had little doubt today. Anyway, my employer will pay for me to take each test once. I got the second one free, so I am free and clear. Thanks, Microsoft! :)
Wednesday, March 30, 2005
Wednesday, March 23, 2005
Visual Studio Web App Debugging
My current solution holds 32 projects. Many of the projects in my solution hold project references to other projects within the solution. The project references make XCopy deployment of our web app quick and easy. No problems here, right? Wrong! After many weeks of attempting to debug my web app, the debugger seemed to work in a very hit and miss fashion.
Here is the scenario...I have VS open. I make changed to a domain object class. I go to the Debug menu and select Run. My breakpoint are hit, and life is wonderful. Here is the catch. I stop debugging and make some more changes. I do to the Debug menu and select Start. This time, when my page opens in the browser, I get an error that the WebControls.dll can't be found. WTF?!? I stop debugging. I rebuild the solution outside of the debugger. Everything appears to be fine. I start the debugger again, only to see the same error. Okay, no need to panic. I will just close down VS and reopen (which becomes quite a lengthy chore if you are working over VPN and your solution gets the lastest version on load). That being done, I rebuild. No errors, everything looks fine. I start the debugger. By this point, about half of the time, the error is gone and things are fine. But the other half of the time, the error is STILL THERE!!! So what do I do? Occassionally I follow the theory that if I try the same thing over and over without changing anything, it is bound to work sooner or later, so I close down VS, reopen it, and give it another try. Eventually, I throw my hands up in the air and restart my machine. That always fixes the problem.
The thing is, it is difficult to meet estimate deadlines when I have to restart my machine at sporatic times throughout the day.
I am in no way suggesting that in my elevated state of frustration, it is impossible that I overlooked a simple and quick fix to my issue.
After being forcefully exposed to my rants, my co-worker, the JavaKid, finally asked me what was going on and how could he help. I told him that there was nothing he could do because the problem was that VS was the suckiest IDE in existance, end of story. Although the JavaKid loves to hear about the ways Microsoft can improve, he did ask me why I would choose to run the debugger in the way I was using it. He told me that there is a better way to debug a web app. So, to make a long story short (too late, huh?), he told me that it works much nicer with a web app if instead of selecting Debug/Start, you right click on the page you want to launch, View it in Browser (at which point I am fuming because I do NOT want to view it in browser, I want to DEBUG). Once the page is loaded in the browser, select Debug/Processes. In the list of processes, select aspnet_wp.exe, click Attach, and hit Okay. Now we are debugging! Since I have followed his advice, I have not seen that nasty error.
So the moral is: When building a web app, although the play button looks shiny and tempting, DO NOT PRESS IT! Attach to your running process instead. This tip has saved me many hours.
Also, if you tend to get the error about a resource cannot be copied because it is use by another process, try disabling your Indexing service and restarting IIS.
Here is the scenario...I have VS open. I make changed to a domain object class. I go to the Debug menu and select Run. My breakpoint are hit, and life is wonderful. Here is the catch. I stop debugging and make some more changes. I do to the Debug menu and select Start. This time, when my page opens in the browser, I get an error that the WebControls.dll can't be found. WTF?!? I stop debugging. I rebuild the solution outside of the debugger. Everything appears to be fine. I start the debugger again, only to see the same error. Okay, no need to panic. I will just close down VS and reopen (which becomes quite a lengthy chore if you are working over VPN and your solution gets the lastest version on load). That being done, I rebuild. No errors, everything looks fine. I start the debugger. By this point, about half of the time, the error is gone and things are fine. But the other half of the time, the error is STILL THERE!!! So what do I do? Occassionally I follow the theory that if I try the same thing over and over without changing anything, it is bound to work sooner or later, so I close down VS, reopen it, and give it another try. Eventually, I throw my hands up in the air and restart my machine. That always fixes the problem.
The thing is, it is difficult to meet estimate deadlines when I have to restart my machine at sporatic times throughout the day.
I am in no way suggesting that in my elevated state of frustration, it is impossible that I overlooked a simple and quick fix to my issue.
After being forcefully exposed to my rants, my co-worker, the JavaKid, finally asked me what was going on and how could he help. I told him that there was nothing he could do because the problem was that VS was the suckiest IDE in existance, end of story. Although the JavaKid loves to hear about the ways Microsoft can improve, he did ask me why I would choose to run the debugger in the way I was using it. He told me that there is a better way to debug a web app. So, to make a long story short (too late, huh?), he told me that it works much nicer with a web app if instead of selecting Debug/Start, you right click on the page you want to launch, View it in Browser (at which point I am fuming because I do NOT want to view it in browser, I want to DEBUG). Once the page is loaded in the browser, select Debug/Processes. In the list of processes, select aspnet_wp.exe, click Attach, and hit Okay. Now we are debugging! Since I have followed his advice, I have not seen that nasty error.
So the moral is: When building a web app, although the play button looks shiny and tempting, DO NOT PRESS IT! Attach to your running process instead. This tip has saved me many hours.
Also, if you tend to get the error about a resource cannot be copied because it is use by another process, try disabling your Indexing service and restarting IIS.
Monday, March 21, 2005
JavaScript - Bigger and Better?
I read an article today about the possible future of personal computer use, called
Goodbye, computer; hello, world! . In a nutshell, this article talked about an idea that may or may not be underway right now at Google. The idea is that Google would create their own operating system and allow users to subscribe to their mega-computer that would hold all of their personal applications. Theoretically, this would make the need for storing data on a PC obsolete. You could now travel to Geneva without lugging around your laptop and just hop on a computer over there, login, and voila! All of your applications are at your fingertips.
Okay, that would probably work for some non-proprietary data needs. I might feel comfortable publishing out my Quicken data to Google, as long as my privacy was guaranteed. I am not so sure this would ever work for business-level data, however.
Then came the part of the article that made me squirm. In order for this throw-away-your-PC model to work, web applications would have to become quicker. I will just quote directly the line about the technologies that Google is looking to use to assist their team in creating web apps that are as fast as desktop applications. This new marriage of technologies is called Ajax.
“Ajax, which is short for Asynchronous JavaScript + XML, combines JavaScript, dynamic HTML, and XMLHTTP to, in essence, let you build Web-based applications that run as quickly and seamlessly as local software.”
Maybe I am alone in this, but the idea of working with JavaScript as my programming language of choice is not a pleasant prospect. Actually, relying on any scripting language is something of which I would prefer to steer clear.
But it would be very cool to be able to write my applications for the web without having to be as considerate of loading and post back speed. And having an engine manage asynchronous requests from my web app to speed responsiveness would be very cool. So is it time for me to dig back out my JavaScript books that I have hoped to forget existed?
Goodbye, computer; hello, world! . In a nutshell, this article talked about an idea that may or may not be underway right now at Google. The idea is that Google would create their own operating system and allow users to subscribe to their mega-computer that would hold all of their personal applications. Theoretically, this would make the need for storing data on a PC obsolete. You could now travel to Geneva without lugging around your laptop and just hop on a computer over there, login, and voila! All of your applications are at your fingertips.
Okay, that would probably work for some non-proprietary data needs. I might feel comfortable publishing out my Quicken data to Google, as long as my privacy was guaranteed. I am not so sure this would ever work for business-level data, however.
Then came the part of the article that made me squirm. In order for this throw-away-your-PC model to work, web applications would have to become quicker. I will just quote directly the line about the technologies that Google is looking to use to assist their team in creating web apps that are as fast as desktop applications. This new marriage of technologies is called Ajax.
“Ajax, which is short for Asynchronous JavaScript + XML, combines JavaScript, dynamic HTML, and XMLHTTP to, in essence, let you build Web-based applications that run as quickly and seamlessly as local software.”
Maybe I am alone in this, but the idea of working with JavaScript as my programming language of choice is not a pleasant prospect. Actually, relying on any scripting language is something of which I would prefer to steer clear.
But it would be very cool to be able to write my applications for the web without having to be as considerate of loading and post back speed. And having an engine manage asynchronous requests from my web app to speed responsiveness would be very cool. So is it time for me to dig back out my JavaScript books that I have hoped to forget existed?
Friday, March 11, 2005
Visual Basic 6.0 Petition
If you have been reading my blog since the start, you will know that I come from a Visual Basic background. My first experiences delivering solutions to my business clients came in the form of VB 6.0 windows applications. I even occasionally opened the dreadful IDE that was Visual InterDev. Wow, did that ever suck. I thought it was pretty cool at the time, considering my other alternative of FrontPage and notepad if I wanted to develop on the Microsoft platform.
I also was very supportive of VB.net. I couldn't wait to get my hands on the first beta of the .net framework.
I did have to deal with some pains when it came to the applications I built using VBScript or VB 6.0 once the .net Framework was around. There really is no way that I have found to easily port code from 6.0 to .net. I had to decide for each of my client application's if I thought it would be better to continue to support the application in 6.0 or if it would be better to re-write the app in .net. After working with .net for a couple of weeks, I never wanted to go back to 6.0. Whenever I had the chance, I upgraded my clients. I even estimated an upgrade at about a tenth of the actual cost and resolved myself to doing the rest of the work for free in my personal time just so that I would not have to use Visual Studio 6.0 any more.
That is why I have trouble understanding the purpose of this "Save VB 6.0" petition that has been ciruclating. I understand how there may be very large legacy systems built in older versions of Visual Basic, but come on. Microsoft has continued to support Visual Basic 6.0 for years since the .net release. For legacy code, wrap it, convert it, or leave it. Again, it is completely possible that I missing the whole point, so if I am, please enlighten me. But I do not understand why Microsoft should continue to support an out-dated language. I am sure there are applications written in Lotus 1-2-3 that are still running out there, too. Is there still support for Lotus 1-2-3? Gosh, I hope not. What a dreary life that would be if you were the support person.
So VB 6.0 is a thing of the past. As a Visual Basic language supporter, I ask, what is so wrong with that?
I also was very supportive of VB.net. I couldn't wait to get my hands on the first beta of the .net framework.
I did have to deal with some pains when it came to the applications I built using VBScript or VB 6.0 once the .net Framework was around. There really is no way that I have found to easily port code from 6.0 to .net. I had to decide for each of my client application's if I thought it would be better to continue to support the application in 6.0 or if it would be better to re-write the app in .net. After working with .net for a couple of weeks, I never wanted to go back to 6.0. Whenever I had the chance, I upgraded my clients. I even estimated an upgrade at about a tenth of the actual cost and resolved myself to doing the rest of the work for free in my personal time just so that I would not have to use Visual Studio 6.0 any more.
That is why I have trouble understanding the purpose of this "Save VB 6.0" petition that has been ciruclating. I understand how there may be very large legacy systems built in older versions of Visual Basic, but come on. Microsoft has continued to support Visual Basic 6.0 for years since the .net release. For legacy code, wrap it, convert it, or leave it. Again, it is completely possible that I missing the whole point, so if I am, please enlighten me. But I do not understand why Microsoft should continue to support an out-dated language. I am sure there are applications written in Lotus 1-2-3 that are still running out there, too. Is there still support for Lotus 1-2-3? Gosh, I hope not. What a dreary life that would be if you were the support person.
So VB 6.0 is a thing of the past. As a Visual Basic language supporter, I ask, what is so wrong with that?
Subscribe to:
Posts (Atom)