I finally can't resist a quick rant about VS Express...
I'm currently in the process of designing a fairly complicated website and as part of this it became necessary that I develop a custom ASP.NET Server Control as a component to be used by a couple pages within the site. Now, I read my way through a few tutorials about this (including some of the MSDN docs), and concluding it was simple enough I created a simple class inheriting from WebControl and specifying the ToolboxData attribute, but soon ran into problems. It seems that another annoying limitation of the Express editions of Visual Studio is that you can't develop a website and an associated library (a control library in this case) side by side, since Visual Web Developer locks the DLL file when running its web server. This of course means you can't build any referenced library while the web server is running. Okay, so this by itself is expected (albeit irritating) behaviour and there's probably little anyone could do about it - but then I thought that I would at least be able to build the referenced library once I'd stopped the web server. To my regret I found that Visual WD maintains the lock on the referenced DLL, forcing me to completely close off the IDE before I can rebuild the helper library (in VB.NET or VC# Express), and then reload the IDE and restart the webserver before I can continue testing! Well I think you see the point by now...
I've always been quite pleased since Microsoft made available their main programming languages to those of us (mainly students) who can't afford the paid editions or aren't inclined to get it over BitTorrent. However, I am surely starting to lament the absence of a .NET IDE that can handle multiple language/project types...
Subscribe to:
Post Comments (Atom)
7 comments:
Oh, I ought to point out before someone else (David?) that switching over to Eclipse/SharpDevelop (or even ditching Windows and working with Mono/MonoDevelop) wouldn't a the best idea while .NET 3.5/VS 2008 is being released and seemingly leaving most else in the dust.
[/rant]
Still: lol "crippleware", and lol "locking libraries, even after your linker/loader has finished with them". I think I'll stick to python[+unix] for a while longer.
Indeed, you summarised well. *sigh* You have your point about sticking to python/unix but I do believe that IronPython can be compiled into the same VM code as VB.NET/C# now, which puts it on the same footing as other python implementations, or even ahead considering it has the whole .NET framework to work with. Could be interesting now that you can use it with Silverlight too... And it may be an easier way to move myself over to Linux than dealing with lagging Mono.
Seems like this could explain it. Also seems like I can turn it off for the whole system, but I'm wondering if that's really going to kill performance. Oh, why couldn't the Windows devs have thought of process specific (memory) settings? *excepts reply telling me unix has had this for aeons*
Having a dll loaded into memory is no reason to lock it. The file only needs to be locked when you are *physically reading from it or writing to it*.
Not sure what you're talking about with regards process specific memory settings.
Well if this DLL issue *is* the cause, then maybe it would be useful to specify how a certain program should manage memory in relation to DLLs (and maybe other things)...
If you are a university student probably your university has the MSDN Academic Alliance where you can get all Microsoft development software for free (that includes Visual Studio professional, but not VSTS). Try to get info about that, it's a pretty interesting thing :)
Regards,
Vicente
Post a Comment