|
I recommend you simply start developing your main application. As you discover generic classes/methods that you use (or will use) in multiple places, extract them out to your utility DLL. If these classes belong to a particular area (web, windows, gui, networking), you may consider adding them to a more specific utility DLL.
That's the quickest and easiest way to build up your library of reusable classes.
Regards,
Alvaro
Give a man a fish, he owes you one fish. Teach a man to fish, you give up your monopoly on fisheries.
|
|
|
|
|
I disagree with Alvaro - and many other architects will as well. Start by planning your application. Before writing a single line of code, decide what can be abstracted into separate modules. But start writing code by writing a good toolkit/framework. You should write them generically enough (using a provider pattern, good abstract object model, etc.) so that they can be reused in other applications.
Writing monolithic applications is always a bad idea. Starting from the UI and peeling pieces away will eventually lead to problems where your framework isn't generic enough for abstract use. This is a similar problem found when securing applications - security should never be an afterthought. Neither should a good application design.
Take a look at the .NET Framework Class Library. The assemblies mscorlib and System comprise the base functionality that everything uses. System.Windows.Forms and System.Web for example, could work without the types in those assemblies (nor could anything else - especially without the mscorlib assembly). It's all based on a good foundation.
If you're looking for good books (and the ones I'm recommending are free to download in their entirety), see the MSDN Patterns and Practices[^] site.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Heath Stewart wrote:
I disagree with Alvaro - and many other architects will as well. Start by planning your application. Before writing a single line of code, decide what can be abstracted into separate modules. But start writing code by writing a good toolkit/framework. You should write them generically enough (using a provider pattern, good abstract object model, etc.) so that they can be reused in other applications.
I think we're referring to two different concepts. You're talking about application design, which of course should be done before coding. I was referring to the creation of generic class libraries for use in multiple applications. I argue that those are developed slowly, as the need arises.
For example, say you start programming a Sockets-related project and you notice that the .NET classes don't have a couple of methods that would be really convenient for you. So you develop your own SocketUtil class, add the methods, and build it into your generic Util DLL.
That's how I've created my utility classes over the years, and I argue that most developers (not architects) have created theirs too. In fact, I'm willing to bet that most of the class libraries and utilities published in CP originated because someone had an immediate need for some functionality that they then extracted into a separated module for reuse.
Regards,
Alvaro
Give a man a fish, he owes you one fish. Teach a man to fish, you give up your monopoly on fisheries.
|
|
|
|
|
Designing applications will lead to class libraries. Writing a toolkit is hardly a backward process. Yes, realizing that additional features could be abstracted from applications often happens, but even writing multiple applications at the same time and saving stuff off doesn't really make for a good class library from which applications should be based.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
When you design an application, you usually talk about the classes that will play a role in the life of the application. Classes such as Customer, Order, Product, etc, are application-specific classes that are designed to meet that particular application's needs. You can put them inside a separate DLL and call them a "class library" if you like, but chances are that they'll only be used by one application.
As you start developing the application, you'll notice that the underlying class library (.NET) will not provide all the functionality you need. So you'll end up extracting some of that functionality into a separate DLL to become part of a generic class library.
The main difference between the application-specific class library (A) and the generic one (G) is that A needs to be created/considered every time an application is started, while G is always there and continues to grow as more applications are written.
Regards,
Alvaro
Give a man a fish, he owes you one fish. Teach a man to fish, you give up your monopoly on fisheries.
|
|
|
|
|
You must deal with small applications with a limited scope, then.
I'm talking about interfaces, abstract control classes, utility classes like a preferences provider pattern, configuration sections for those classes, etc. etc.
The framework I architected for our large industrial engineering application is vast and not application-specific until you get a little further up the dependency hierarchy.
Microsoft Office is the same: They have their toolbar code, their their persistence code, the task bar code, etc. They get used in all the products. It's a very abstract design that is not really product specific (depending on your scope of "product").
I guess it really matters what you need to abstract away. Many applications start with a UI toolkit and that tends to get reused throughout a company.
Another factor is that there isn't too levels of abstraction when it comes to toolkits vs. applications. Typically there's many, as with our application. There's a base toolkit (UI, persistence model, COM-like interfaces), a goal-oriented tookit on top of that with additional features, a product-specific toolkit, then the application itself.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Thanks for the insight.
I admit I've never had to build something that large. It's usually been broken in 3 layers:
1. Generic Toolkit (reusable across applications, continually growing)
2. Application Toolkit (reusable within the application, sometimes extending Generic)
3. Application classes (usually extending the Application toolkit)
Regards,
Alvaro
Give a man a fish, he owes you one fish. Teach a man to fish, you give up your monopoly on fisheries.
|
|
|
|
|
Hey Guys!
I am currently working on a Project, but now facing a problem  in how to Monitor a Specific port for Data that is going from my computer to the outer world. E.g. I want to monitor port 'xyz' to check what is goind outside from my computer through this port.
Can anybody help me to solve this problem.
Give Room to Grow your Knowledge by Sharing your Experiences with Others
|
|
|
|
|
Download WinPcap and the associated Analyzer from http://winpcap.polito.it/[^]. You can also use Ethereal (port from *nix), but that still requires the WinPcap library (which, in case you're wondering, is partly founded by Microsoft so it's pretty safe and it is a common lib to find IT-folk using).
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
In Command-Mode (in VS.NET) I entered (after a breakpoint):
sLine.IndexOf("\"OPEN\",\"OPEN\"")
and got:
error: 'sLine.IndexOf' does not exist
why that?
sLine got a value as
string sLine="blabla";
Ariadne
|
|
|
|
|
When you opened the Command Windows and typed sLine.IndexOf("\"OPEN\",\"OPEN\""), was it after a > prompt? If so, this is your problem. You can make evaluations in Command Mode, but you can't execute code. You have to switch to Immediate Mode first by issuing the immed command.
...Open a Command Window to Ctrl-Alt-A...
Command Window
>immed
sLine.IndexOf("\"OPEN\",\"OPEN\"");
cmd
>_
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
no that is not the problem. I am in the immed-mode.
I get the value of
sLine<br />
sLine.Length
but not of any method of sLine like
sLine.IndexOf(..)<code><br />
<br />
<br />
Ariadne
|
|
|
|
|
I don't have that problem at all. Are you sure sLine is a String?
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
I have a c++ application that needs to retrieve information from my company's server. I decided to build a c# webservice. So far it works fine. I need to add some security since I pass userid and password. But my main concern is that this webservice will only be used by our applications and I don't want it to be public to others, so that they cannot view the schema and cannot see the page that shows how to make a HTTP GET/POST and SOAP request.
Is there a way to make the webservice not available to public ? or at least hide the schema/request pages ?
|
|
|
|
|
If you're looking to add security to your web services, take a look at the Microsoft Web Service Enhancements (WSE)[^]. 2.0 was recently released. With a few simple changes to your server and clients, you can use strong authentication protocols (or a simple username/password, though I recommend at least hashing the password using MD5 or SHA1, which is easily supported by the WSE), encryption, signatures, addressing (routing), etc.
If you want it private, simply don't expose it to the public. Unless it needs to be on your Internet web server, just use it on your intranet. If you need to put it on your Internet server (say, for an extranet) then use IP address blocking (IIS feature) or features in the WSE. The latter won't prevent them from seeing the WSDL, but unless your business is about the WSDL schema and not the data that's transferred, this really shouldn't be a problem.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Heath Stewart wrote:
If you're looking to add security to your web services, take a look at the Microsoft Web Service Enhancements (WSE)[^].
The client application is built under VC++ 6.0. So, for now I am using sockets to connnect and retrieve the information. I was thinking about using SSL socket. I think there are some examples on codeproject.
Heath Stewart wrote:
If you want it private, simply don't expose it to the public. Unless it needs to be on your Internet web server, just use it on your intranet
The client application is a Windows application that access the service through the Internet. It connects to our company's Web server and retrieve some data to process/display. My main concern is that service should only be available to the client applications and not to the public. If I could hide the shema returned when you point a browser to the .asmx file, that would be a good start. Then there is the ?WSDL.
It looks like there is no easy way and will have to write a .ASP page which does basically the same thing. The problem is returning the XML code, with a webservice it's all very easy.
Possible solution: Have the .ASP page call the webservice, which would not be public, and simple return the data. The .ASP would just act as a bridge between client and webservice.
|
|
|
|
|
Everything from handling requests to .asmx?WSDL to generating the WSDL itself (as well as the "human-readable" HTML output for a service) is configurable. Spend some time reading the class library documentation for the System.Web.Services and child namespaces.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Here's what I found:
Since this webservice will only be used by some client applications that already knows the schema, to hide the documentation of the web service, there is a key that can be set in the web.config file.
<br />
<?xmlversion="1.0" encoding="utf-8"?><br />
<<configuration><br />
<system.web><br />
<!--<br />
HIDE THE DOCUMENTATION FOR THE WEB SERVICE<br />
--><br />
<webServices><br />
<protocols><br />
<remove name="Documentation"/><br />
</protocols><br />
</webServices><br />
</system.web><br />
</configuration><br />
|
|
|
|
|
You can also set a custom page to be displayed for the WSDL documentation:
<?xmlversion="1.0"encoding="utf-8"?>
<configuration>
<system.web>
<!--
Custome help page\
-->
<webServices>
<wsdlHelpGeneratorhref="helpPage.aspx"/>
</webService>
</system.web>
</configuration>
It can also be a .html page. So you can display what ever you want.
A third possibility is to process the request from Application_BeginRequest function. You can check if the request has a ?wsdl to it and throw a http exception.
All these examples can be found here: http://www.15seconds.com/issue/040609.htm
|
|
|
|
|
is there any way to promote programatically a directory
(located within inetpub directory subtree) to web application?
Also I would like programatically add new IASPI mapping
(for some custom file extension to particular DLL)
for this newly created web application.
Thanks for help
Michał Januszczyk
|
|
|
|
|
You can do both programmatically using either the IIS WMI provider or the ADSI provider.
For the WMI provider, use the System.Management classes, and for the ADSI provider use the System.DirectoryServices classes.
Try the following google search for lots of examples or refine it to find exactly what you want. Documentation for the IIS WMI and ADSI providers can be found on MSDN[^].
http://www.google.com/search?q=add+virtual+directory+programmatically+to+iis[^]
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Thank You!
This is exactly what I needed.
|
|
|
|
|
Hi EveryBody,
I used the later code to handle some messages sent to my application
and it works, but my question is how to handle messages sent for child applications of my application(parent)
<br />
[System.Security.Permissions.PermissionSet(System.Security.Permissions.SecurityAction.Demand, Name="FullTrust")]<br />
protected override void WndProc(ref Message m)<br />
{<br />
switch (m.Msg)<br />
{<br />
<br />
case WM_SIZING:<br />
MessageBox.Show("Sizing");<br />
return ;<br />
case WM_SIZE:<br />
MessageBox.Show("Size");<br />
if(m.WParam==(IntPtr)SIZE_MINIMIZED)<br />
MessageBox.Show("SIZE_MINIMIZED");<br />
else if(m.WParam==(IntPtr)SIZE_MAXIMIZED)<br />
MessageBox.Show("SIZE_MAXIMIZED");<br />
return;<br />
<br />
case SW_MAXIMIZE:<br />
MessageBox.Show("SW_MAXIMIZE");<br />
return;<br />
<br />
case WM_MOVING:<br />
MessageBox.Show("Moving");<br />
return;<br />
}<br />
base.WndProc(ref m);<br />
}<br />
<br />
Please I need a very fast help.
Thank you .
|
|
|
|
|
Child applications? There's no such thing. Are you talking about child Windows or MDIChildren? Each form has it's own message pump. Your parent form will not get the messages meant for child forms.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Dave's right about the message pump. Some controls will send their parents messages, and these are documented in the Platform SDK (almost every control in Windows Forms encapsulates Windows Common Controls).
There is another way, though. Implement the IMessageFilter interface and add an instance of your implementation using Application.AddMessageFilter. This installs a message filter for the application's message pump, which will trap messages and allow you to process them (or even remove them) before dispatching them to their destination windows.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
