June 2003 - Posts
i had to jump up in front of the arizona .net user group
the other night to give a quick impromptu introduction since our guest speaker was a little late getting started. thing is, it got recorded and uploaded
feel free to watch and make suggestions, i'm always looking to improve.
yeah, it sounds a little obtuse and everything, but there's a new company
who's decided that neither java nor .net are reliable, "easy-enough" platforms to facilitate 4GL applications.
first quote that's bs-laden and, in my opinion, rather offensive to those of us already using these tools is this one: "i say C# and Java are too complex to write business applications." my bsometer went nuts when i read this. apparently, those of us who are using either - or both - of these platforms have proven this guy (the CEO of the company, i might add) to be totally full of it.
second quote - "There's been a lot of 4GLs … but none of them have achieved mass market adoption to have tools and capabilities around them." uh hello BEA, WebLogic, .NET, COM+? seems to me that the market is somewhat fluttering with these tools, that have been proven effective.
finally - its obvious to this author that Genero (superior dumb name for a company) is in this thing for the cash - the price tags - $400 per user and $15,000 per CPU (i'm assuming for the application server).
gimme a stinkin break. the market has no room for you, so get out of it.
i was using the Assembly.LoadFrom method, with the first constructor. basically, i haven't been passing in any securit evidence. so, this obviously won't work. now i'm totally interested in this stuff. yet another digression.
if you didn't read the post before this, go read it. ok. here's the fix.
in studio, i had four projects open - my repository/testing area, fyi. a console app (for basic testing), a web app, a windows app, and a library. all c# (duh).
in my library, i have a series of components which aim themselves at attributes located on methods placed throughout an assembly. using the Assembly.LoadFrom(string) overload, i take a snapshot via reflection at every Type within the assembly.
an inner loop of this runs through each method (will be extended to include everything) in the Type and investigates each custom attribute on the method. in essence, it's searching for an attribute of type IssueAttribute. for each of these that is found, its values are used as parameters for an external method. a DataTable representation of the results is returned from the method.
that's your reverse-engineering lecture....
anyhoo, when i executed this app from the aspx project and pointed it to the assembly that had been copied up to the /bin directory, it worked just fine. when i ran the windows app, i used an OpenFileDialog to locate the assembly. the filename i was using was the one that was stored in the aspx apps /bin folder.
on a whim, i ran the client app again and pointed it to the dll that had been stored in the /bin folder of the windows app this time. voila! it worked and executed precisely as i had originally expected.
this is a very interesting behavior i think. seems that the aspx application (i'm totally guessing here, and really want the answer so if you know hook me up) was restrciting access to the internal loop - the process inspecting the type via an as casting (see the code)! when i performed said procedure in the client app, the web app's dll was not - don't know how to put this - "logically registering" or something. is this evidence of app domain security (thinking that the aspx application was still using the original dll and disallowing access to external apps, maybe)?
how does this work? or is it simply something i just failed to pick up along the way?
i'm having a very weird problem with attributes.
see, i've got this custom attribute. i use this attribute in an assembly. then, i load that assembly from a filepath. i run through all the types in the assembly and look for the attributes. here's some code that demonstrates this behavior:
private void AddMethodTraqIssue(Type t, ref IssueCollection issueCollection)
foreach(MethodInfo mi in t.GetMethods())
foreach(Attribute att in mi.GetCustomAttributes(true))
Repository.IssueTracker.IssueAttribute attIssue =
att as Repository.IssueTracker.IssueAttribute;
if(attIssue != null)
// TODO: don't leave this concatenation in here during production release.
Issue issu = new Issue(attIssue,mi.Name,t.Namespace + "." + t.Name);
// make sure we've got a valid collection with something in it
if(issueCollection == null)
issueCollection = new IssueCollection(issu);
i execute this code from an aspx page and it works wonderfully. this code, mind you, is in a separate library project that the aspx project has a reference to. i've also got a windows forms project, which calls the same method, with the same parameters on the same dll. guess what - every time i perform the procedure to "get the custom attribute as a specified type of custom attribute," the attribute comes back as "undefined."
weird - it works wonderfully in aspx, but not at all in windows forms. anyone have any ideas?
as of friday, i've secured my mcsd.net certificate. it was a month-and-a-half of stress, studying, and thinking about the courses. i failed 2 tests - sql server and the msf one - throughout the process, but as of friday, i had passed the fifth and final test. so that's it - i've got the cert!