|
vladdy77 wrote: I have a design problem and that's why I came here looking for answers. Is that a crime ?!?
No it's not a crime to come looking for answers to your design issue.
vladdy77 wrote: You will also have to agree that the way he approached was totally unprofessional and uncalled for.
... Trolling won't get him anywhere.
I don't think he was out of line with his approach.
Some people have a memory and an attention span, you should try them out one day. - Jeremy Falcon
|
|
|
|
|
vladdy77 wrote: There is very little data access in this application as it is basically automating MapPoint with their dispatch system and that's why n-tier architecture with gui/bus/data layer is not very applicable to this project.
n-tier doesn't have to mean "gui/bus/data" as you put it. I look at it as separating the inputs and outputs from the business layer. The business layer is the glue that holds it all together. The GUI is an input/output layer, just like the database is another type of input/output layer. I tend to look at it as hub and spoke design rather than tiers - It happens that the most common is a hub (the business layer) with two spokes (the GUI and the Data).
In your application the GUI is a spoke, MapPoint is another spoke, if you deal with files then that's another spoke.
If you can identify each of these spokes then you can identify what can be split out to other DLLs. Just remember, for anything to communicate with another spoke, it must go through the hub as each of the spokes should be designed to be self contained.
Once you have this you can start adding more spokes in future (say you need a Web front end, or a mobile version, or you start supporting Oracle Spatial, etc.)
vladdy77 wrote: Needless to say that I came from different environment but I guess you "pro's" won't tolerate that.
I think most of us have, at one point, been in a monolithic project that was getting out of control. Those that have now have a severe dislike, even hatred, for that model (also called the Giant Ball of Mud Design Pattern/Paradigm) because it caused so much fustration. I was, for 4 years, on a monolithic project and for 3 of those 4 years I would be trying to persuade people that we really needed to split up the code in to manageable blocks.
|
|
|
|
|
Colin Angus Mackay wrote: n-tier doesn't have to mean "gui/bus/data" as you put it
Exactly. n-tier was never meant to mean this. This is just one (common) use of n-tier architecture. Ironically (speaking mathematically) all systems are n-tier.
Colin Angus Mackay wrote: I think most of us have, at one point, been in a monolithic project that was getting out of control
That brings back so many bad memories.
Arthur Dent - "That would explain it. All my life I've had this strange feeling that there's something big and sinister going on in the world."
Slartibartfast - "No. That's perfectly normal paranoia. Everybody in the universe gets that."
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Dave Kreskowiak wrote: Mark is right. YOu've got a SERIOUS redesign of your application in front of you.
I concur.
Dave Kreskowiak wrote: By splitting up your application into seperate classes, such as a Data Layer, you're actually giving yourself the .DLL's you're looking for!
Excellent point 
Some people have a memory and an attention span, you should try them out one day. - Jeremy Falcon
|
|
|
|
|
Dear friends,
I am using the reflection class in .net to write a reflector which is a simple program that show the content of a assembly.but i have a problem.
if a .dll reference another .dll and they are both in a same directory ,the LoadFrom() method solve my problem.but if they are in different directories i have to browse the referenced one and load it.
Despite of loading the referenced one in application domain,the GetTypes() function of assembly class insist on throwing exception.Why?.I don't know.
I would apprecite your helping hand.
hossein
|
|
|
|
|
What exception is it throwing? Have you wrapped it in a try/catch block and debugged it? Look at the inner exception as well as the exception.
Arthur Dent - "That would explain it. All my life I've had this strange feeling that there's something big and sinister going on in the world."
Slartibartfast - "No. That's perfectly normal paranoia. Everybody in the universe gets that."
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
hi,
thanks for your reply,
this is the message "System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information."
I tried to handle the exception by try /catch. after exception i know that i have to browse the referenced dll to application domain by Assembly.LoadFile() or AssemblyLoadFrom().it loads.but when i re enter to the GetTypes() method of assembly object,it throw again an exception.I mean it does not understand that the referenced dll is in domain.
|
|
|
|
|
I'm developing a serviced component in C#, this component is configured as transaction disabled, each method will either be transactional or not - transactional methods will use SWC ServiceConfig to create a transactional context.
The problem I've found concerns use of the Inheritance property;
If I set the property to Ignore, a new context is created which is not transactional (IsInTransaction = false) and security is not enabled in the new context (which is expected).
If I set the property to Inherit, a new context is created which again is not transactional (IsInTransaction = false) but this time security is enabled in the new context (ok, inherits this from the existing context).
If I don't set the property at all, a new context is created which is transactional (IsInTransaction = true) and security is not enabled in the new context (not sure what to expect at this point  .
The documentation states that this property is defaults to "Inherit", from my experience this doesn't seem to be bourne out - is it a bug 
Environment: XP Pro SP2, VS.NET 2003 SP1, .NET v1.1.4322
I've trawled the internet and not found anything, anyone else come across this??
|
|
|
|
|
Hi,
I am developing an application using the SCSF. I want to display a logon view for users to logon before displaying the Shell form and continue to load the other modules. If the logon fails I want to exit the application and not show the Shell form at all.
I have listed in the ProfileCatalog.xml the order of the modules to be loaded. The "logon" module is the first. But how can I terminate the the application halfway through? It does not respond to "Application.Exit()". It just continues to load the other modules. I also tried to throw an exception but I do not want the exception to be displayed as it is not an error.
Does anyone have any idea on how I can achieve this?
Thanks.
|
|
|
|
|
vijeta_r wrote: Suggest some reusable components that can be built using c#.net
Put on your thinking cap 
You are quite vague in your post. What kind of reusable component do you want to build?
Some people have a memory and an attention span, you should try them out one day. - Jeremy Falcon
|
|
|
|
|
Hi all,
I have a few clickonce apps deployed on company intranet. Recently I experiment a problem with user scoped settings. When I published a new version all my user settings are set to the ones in App.config (default values), this problem didn't happen with previous publishes. This should never happen as Microsoft claims. After that I tried to re-create the problem by changing a lot of things, tempering with the assembly version and guid but I couldn't, user settings are kept.
More recently I did a very small update to the logic in a class, nothing to do with settings. The same problem came again, my user settings were overwritten with default!!!!!!!!
Is there anyone out there have the same problem or solution please help?
Is it framework bug???
Thanks in advance.
Ha Le
www.abc-it.net.au
|
|
|
|
|
hi all
while creating windows service can we use config file, if we can so where we will put this file either in "bin\debug\" or in "bin\release"
i have put my file in bin/release folder . but after creating setup when i start this service so it doest not start ,,, any i dea ?
hello
|
|
|
|
|
Put the config file in the same directory as the executable it configures.
|
|
|
|
|
Your setup would normaly install the service to a folder in "program files" ([Manufacturer]\[AppName]). By default, your app.config file should reside here too.
|
|
|
|
|
Hi Frndz,
I have seen many medium & big size co's prefer C# over VB.NET in various web app.
Why is it so?? Because I do not see any reason for this preference as the compilers & CLRs same for both the language.
So still why do co prefer C# over VB.NET?
Regards,
Vipul Mehta
|
|
|
|
|
VB6 was and is a joke. C# carries an association with C++ ( which it does not deserve ) and VB.NET carries the stigma of VB6, which is in part deserved, as a lot of VB6 nastiness does exist in VB.NET, and a lot of people use VB.NET as VB6, by ignoring the new framework features.
But, you're right, in the hands of a skilled programmer, it's rare to find a project where one language does it better than the other.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Christian Graus wrote: VB6 was and is a joke.
That statement may not be PC, but I couldn't agree more.
|
|
|
|
|
Christian Graus wrote: VB6 was and is a joke.
Never really understood why so many C++ers are so hostile to VB. And I have a C++ background myself. Sure it has deficiencies but it was adequate enough for what it did. C++ has deficiencies too.
I'm using VB .NET now and in fact I'm more irritated by IDE deficiencies compared to C# than language features as such.
Christian Graus wrote: as a lot of VB6 nastiness does exist in VB.NET
Are you talking about use of CInt etc? These are in fact identical to Convert.To... despite being in the Microsoft.VisualBasic namespace.
Kevin
|
|
|
|
|
Kevin McFarlane wrote: Never really understood why so many C++ers are so hostile to VB
I don't understand the hostility either.
If you try to write that in English, I might be able to understand more than a fraction of it. - Guffa
|
|
|
|
|
Add to this that in most cases C# coders, as compared to VB coders, tend to use better coding habits and exhibit more understanding of OO concepts necessary for organization to implement code re-use, etc.
only two letters away from being an asset
|
|
|
|
|
any langauge purely depends on data types.and c# supports strongly typed.
suman
|
|
|
|
|
Personally I think the choice is company specific. Some people willl have a culture that believe serious development is done in C#, others will think that VB has left the VB6 issues long ago.
If a company has a lot of experience with C++ then they would more likely choose to use C#. I personally have moved from C++ to VB.Net and found it not so easy at first.
Check out ARCast - To VB or not to VB at
http://channel9.msdn.com/shows/ARCast_with_Ron_Jacobs[^]
|
|
|
|
|
C++ based programmers have a completely different mindset than VB programmers.
|
|
|
|
|
I'm curious--what if I said that I have a 100% DbC-compliant implementation working on .NET, and that I can prove it? How much would that be worth to the average .NET developer?
I've been doing a lot of research into DbC in .NET for the past three years and I've managed to come up with an implementation that:
-Language independent. It works on any .NET language (even works on VB.NET, heh  )
-Has full support for Pre/postconditions/invariants
-Completely transparent.
-Supports inheritance for all contract checks (that is, it combines preconditions/postconditions/invariants from parent classes correctly into a single contract check)
-Support for contracts declared on .NET interface members
-Support for attribute-based contracts, similar to XC#
-Assertions are completely debuggable. You can step through them just like any other piece of code that you write.
-Support for parameter preconditions. You can write preconditions and apply them to contracts just as easily as you would in XC#.
-Full diagnostic debugging support. If a precondition/postcondition/invariant fails, we can tell you where it failed, what method called it, and we can even assert on that method that caused it to fail.
-Support for class-based accessibility. This library allows you to write preconditions which actually prevent certain types of callers from accessing your code (similar to Eiffel's class-based visibility). For example, you can use this approach to protect internal parts of your code so that they can only be callable from a particular assembly/type/module. This approach prevents library users from using TypeMember.Invoke() to bypass visibility checks in your code because the code itself can check the type identity of the method caller and throw an exception if an unauthorized attempt is made to call the method. Not bad, eh?
Here's a sample contract definition on a single method called Divide:
<br />
public class MathClass<br />
{<br />
public int Divide(int a, [NonZero] int b)<br />
{<br />
return a / b;<br />
}<br />
}<br />
Where NonZero would be a custom precondition attribute defined as:
<br />
[AttributeUsage(AttributeTargets.Parameter)]<br />
public class NonZeroAttribute : IParameterPrecondition<br />
{<br />
#region IParameterPrecondition Members<br />
<br />
public bool Check(InvocationInfo info, ParameterInfo parameter, object argValue)<br />
{<br />
int value = (int)argValue;<br />
return value > 0;<br />
}<br />
<br />
public void ShowErrorMessage(TextWriter stdOut, InvocationInfo info, ParameterInfo parameter, object argValue)<br />
{<br />
stdOut.WriteLine("Parameter '{0}' cannot be zero", parameter.Name);<br />
}<br />
<br />
#endregion<br />
}<br />
So here's how it works: Every time the method Divide is called, my library (called LinFu, short for Language-INdependent Features Underneath) will check the parameters of your method and throw a preconditionviolationexception if the precondition check fails (much like Kevin McFarlane's approach). If the preconditon check fails, it will call ShowErrorMessage and that will be the message applied to the exception.
(Invariants and postconditions can be applied the same way, but for the sake of brevity, I'll leave it omitted).
Now what makes this interesting is that it doesn't matter whether or not you have access to the original source code--you can modify the compiled binary just as easily as if you had the source code in front of you. In fact, the library can modify the binary both dynamically at runtime AND compile time.
So, call this an unabashed advertisement, if you will
Now, I have to ask the Microsoft research people (and anybody else interested) out there--how much would this be worth to you?
|
|
|
|
|
I would suggest first posting an article on this, preferably with an example that people can try out. Then see what interest it generates. If you eventually want to sell it you probably need to effectively get people beta-testing it for a while.
Also, I assume you are aware that MS Research have Spec#, features of which I assume will make their way into .NET eventually.
Kevin
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
