The services, talked here, are things used in IServiceContain er,
IServiceProvide r, etc.
In my opinion, everything can be a service, and a service is generally
used for providing specific features for service consumers, at design
time. But, I think the cnsumers must completely know all aspects of
that service. This sounds not good, and breaks the decoupling rule.
So how to understand the role of Service, in a software engineering
perspective.
Thx in advance.
6  1927 
Hi,
The services, talked here, are things used in IServiceContain er,
IServiceProvide r, etc.
The term "Service" and "Provider", as in IServiceProvide r, refer to specific design patterns (as does "Container" , which is
self-explanatory IMO).
ServiceInterfac e pattern: http://patternshare.org/default.aspx...rviceInterface
The provider pattern decouples a service's implementation with the mechanisms for discovery and consumption. I can't find a
reference to this pattern on patternshare.or g. Maybe someone else has links they could mention.
In my opinion, everything can be a service, and a service is generally
used for providing specific features for service consumers, at design
time.
Many things that aren't commonly referred to as services can be thought of as services, but actually referring to them as services
would create ambiguity when used out of context. For instance, you don't normally call an object's methods, "services" unless you
are creating a logical design. The term "service" is probably overused anyway, but here we are referring to a specific design
pattern.
You can also use these design patterns, as well as the actual interfaces, at runtime. From the perspective of the VS.NET
development team, their application uses them at runtime. You could use these patterns as well in your own applications. You get
some basic support for services in your own applications just by deriving a class from System.Componen tModel.Componen t. Web
services are another example of services being consumed at runtime. There are many, many more examples.
But, I think the cnsumers must completely know all aspects of
that service. This sounds not good, and breaks the decoupling rule.
I don't think a consumer must know all aspects of a service that it consumes, otherwise it would break encapsulation. A service
could very well implement multiple service interfaces if they must share data. The consumer need only be concerned with the
interface on which it's performing it's work.
As for breaking the "decoupling rule", I think the service pattern intends to do just the opposite by creating a loose coupling
between the service implementation and the applications that use it, unless you are referring to a rule of which I'm unaware. I'm
referring to the notion that loose coupling of components is generally better.
So how to understand the role of Service, in a software engineering
perspective.
Thx in advance.
Review design patterns and gather experience if you don't understand them.
--
Dave Sexton
Very appreciated for your detailed explanation.
Yes, I had a misunderstandin g. Service pattern decouples the service
prodiver and the consumer. And the *CONTACT* is the key point which
maintains the interop between the service and the consumer.
I don't know if the following links referring to MS Provider pattern
are the desired stuffs, see, http://msdn.microsoft.com/library/de...sp02182004.asp http://msdn.microsoft.com/library/de...sp04212004.asp
Dave Sexton wrote:
Hi,
The services, talked here, are things used in IServiceContain er,
IServiceProvide r, etc.
The term "Service" and "Provider", as in IServiceProvide r, refer to specific design patterns (as does "Container" , which is
self-explanatory IMO).
ServiceInterfac e pattern:
http://patternshare.org/default.aspx...rviceInterface
The provider pattern decouples a service's implementation with the mechanisms for discovery and consumption. I can't find a
reference to this pattern on patternshare.or g. Maybe someone else has links they could mention.
In my opinion, everything can be a service, and a service is generally
used for providing specific features for service consumers, at design
time.
Many things that aren't commonly referred to as services can be thought of as services, but actually referring to them as services
would create ambiguity when used out of context. For instance, you don't normally call an object's methods, "services" unless you
are creating a logical design. The term "service" is probably overused anyway, but here we are referring to a specific design
pattern.
You can also use these design patterns, as well as the actual interfaces, at runtime. From the perspective of the VS.NET
development team, their application uses them at runtime. You could use these patterns as well in your own applications. You get
some basic support for services in your own applications just by deriving a class from System.Componen tModel.Componen t. Web
services are another example of services being consumed at runtime. There are many, many more examples.
But, I think the cnsumers must completely know all aspects of
that service. This sounds not good, and breaks the decoupling rule.
I don't think a consumer must know all aspects of a service that it consumes, otherwise it would break encapsulation. A service
could very well implement multiple service interfaces if they must share data. The consumer need only be concerned with the
interface on which it's performing it's work.
As for breaking the "decoupling rule", I think the service pattern intends to do just the opposite by creating a loose coupling
between the service implementation and the applications that use it, unless you are referring to a rule of which I'm unaware. I'm
referring to the notion that loose coupling of components is generally better.
So how to understand the role of Service, in a software engineering
perspective.
Thx in advance.
Review design patterns and gather experience if you don't understand them.
--
Dave Sexton
Hi,
Thanks for the links, but the ASP.NET provider pattern is an example of an abstract base class with configuration. I was hoping
there was documentation of a component-based design pattern, one that did not use xml configuration as a part of the solution,
named, "Provider". I guess there is none.
I assume, somewhat like that used by ASP.NET, the pattern consists of an abstract base class that is the contract being "provided",
a concrete implementation of that contract, a strong-typed collection for that contract, an abstract service class that exposes that
collection as a property and a default "provider" as a property, and a concrete implementation of the service class. The service
could also be an interface implementation, which is usually how services are exposed to consumers through a provider.
Sound good or have I described a different pattern altogether?
The goal of the pattern, IMO as I stated in my previous post, is to decouple a service's implementation with the mechanisms for
discovery and consumption. I guess "mechanisms " is a pretty lose term and that view, if accurate, would explain why there is no
definitive "Provider" pattern.
--
Dave Sexton
"dotNeter" <Bu************ @gmail.comwrote in message news:11******** *************@i 3g2000cwc.googl egroups.com...
Very appreciated for your detailed explanation.
Yes, I had a misunderstandin g. Service pattern decouples the service
prodiver and the consumer. And the *CONTACT* is the key point which
maintains the interop between the service and the consumer.
I don't know if the following links referring to MS Provider pattern
are the desired stuffs, see,
http://msdn.microsoft.com/library/de...sp02182004.asp
http://msdn.microsoft.com/library/de...sp04212004.asp
Dave Sexton wrote:
>Hi,
The services, talked here, are things used in IServiceContain er,
IServiceProvide r, etc.
The term "Service" and "Provider", as in IServiceProvide r, refer to specific design patterns (as does "Container" , which is
self-explanatory IMO).
ServiceInterfa ce pattern:
http://patternshare.org/default.aspx...rviceInterface
The provider pattern decouples a service's implementation with the mechanisms for discovery and consumption. I can't find a
reference to this pattern on patternshare.or g. Maybe someone else has links they could mention.
In my opinion, everything can be a service, and a service is generally
used for providing specific features for service consumers, at design
time.
Many things that aren't commonly referred to as services can be thought of as services, but actually referring to them as
services
would create ambiguity when used out of context. For instance, you don't normally call an object's methods, "services" unless
you
are creating a logical design. The term "service" is probably overused anyway, but here we are referring to a specific design
pattern.
You can also use these design patterns, as well as the actual interfaces, at runtime. From the perspective of the VS.NET
development team, their application uses them at runtime. You could use these patterns as well in your own applications. You
get
some basic support for services in your own applications just by deriving a class from System.Componen tModel.Componen t. Web
services are another example of services being consumed at runtime. There are many, many more examples.
But, I think the cnsumers must completely know all aspects of
that service. This sounds not good, and breaks the decoupling rule.
I don't think a consumer must know all aspects of a service that it consumes, otherwise it would break encapsulation. A service
could very well implement multiple service interfaces if they must share data. The consumer need only be concerned with the
interface on which it's performing it's work.
As for breaking the "decoupling rule", I think the service pattern intends to do just the opposite by creating a loose coupling
between the service implementation and the applications that use it, unless you are referring to a rule of which I'm unaware.
I'm
referring to the notion that loose coupling of components is generally better.
So how to understand the role of Service, in a software engineering
perspective.
Thx in advance.
Review design patterns and gather experience if you don't understand them.
--
Dave Sexton
A mechanism for discovery and consumption?
Interfaces are enough for exposing what consumers can do, then why
still need discovery?
I'm a little confused. Is it the reason that there is no real provider?
I guess.
Dave Sexton wrote:
Hi,
Thanks for the links, but the ASP.NET provider pattern is an example of an abstract base class with configuration. I was hoping
there was documentation of a component-based design pattern, one that did not use xml configuration as a part of the solution,
named, "Provider". I guess there is none.
I assume, somewhat like that used by ASP.NET, the pattern consists of an abstract base class that is the contract being "provided",
a concrete implementation of that contract, a strong-typed collection for that contract, an abstract service class that exposes that
collection as a property and a default "provider" as a property, and a concrete implementation of the service class. The service
could also be an interface implementation, which is usually how services are exposed to consumers through a provider.
Sound good or have I described a different pattern altogether?
The goal of the pattern, IMO as I stated in my previous post, is to decouple a service's implementation with the mechanisms for
discovery and consumption. I guess "mechanisms " is a pretty lose term and that view, if accurate, would explain why there is no
definitive "Provider" pattern.
--
Dave Sexton
"dotNeter" <Bu************ @gmail.comwrote in message news:11******** *************@i 3g2000cwc.googl egroups.com...
Very appreciated for your detailed explanation.
Yes, I had a misunderstandin g. Service pattern decouples the service
prodiver and the consumer. And the *CONTACT* is the key point which
maintains the interop between the service and the consumer.
I don't know if the following links referring to MS Provider pattern
are the desired stuffs, see,
http://msdn.microsoft.com/library/de...sp02182004.asp
http://msdn.microsoft.com/library/de...sp04212004.asp
Dave Sexton wrote:
Hi,
The services, talked here, are things used in IServiceContain er,
IServiceProvide r, etc.
The term "Service" and "Provider", as in IServiceProvide r, refer to specific design patterns (as does "Container" , which is
self-explanatory IMO).
ServiceInterfac e pattern:
http://patternshare.org/default.aspx...rviceInterface
The provider pattern decouples a service's implementation with the mechanisms for discovery and consumption. I can't find a
reference to this pattern on patternshare.or g. Maybe someone else has links they could mention.
In my opinion, everything can be a service, and a service is generally
used for providing specific features for service consumers, at design
time.
Many things that aren't commonly referred to as services can be thought of as services, but actually referring to them as
services
would create ambiguity when used out of context. For instance, you don't normally call an object's methods, "services" unless
you
are creating a logical design. The term "service" is probably overused anyway, but here we are referring to a specific design
pattern.
You can also use these design patterns, as well as the actual interfaces, at runtime. From the perspective of the VS.NET
development team, their application uses them at runtime. You could use these patterns as well in your own applications. You
get
some basic support for services in your own applications just by deriving a class from System.Componen tModel.Componen t. Web
services are another example of services being consumed at runtime. There are many, many more examples.
But, I think the cnsumers must completely know all aspects of
that service. This sounds not good, and breaks the decoupling rule.
I don't think a consumer must know all aspects of a service that it consumes, otherwise it would break encapsulation. A service
could very well implement multiple service interfaces if they must share data. The consumer need only be concerned with the
interface on which it's performing it's work.
As for breaking the "decoupling rule", I think the service pattern intends to do just the opposite by creating a loose coupling
between the service implementation and the applications that use it, unless you are referring to a rule of which I'm unaware.
I'm
referring to the notion that loose coupling of components is generally better.
So how to understand the role of Service, in a software engineering
perspective.
Thx in advance.
Review design patterns and gather experience if you don't understand them.
--
Dave Sexton
Hi,
I see a "provider" as providing one or more services so that services can be "discovered " at runtime, instead of just directly
accessing a class that implements a service.
For instance, say that I know of a service interface that exposes methods for logging. The interface provides a loose coupling
between an implementation of logging, which can be file-based or use the event log service (another service), and the consumer.
However, as a consumer I would still need to acquire an implementation of that interface. If I know of a class named,
"EventLogServic e" that implements the logging service interface I could create an instance of that class, however the provider
pattern would enable a different mechanism for discovery. Using a provider I'm able to discover services at runtime based on a
specific service interface without being aware of the mechanisms for service registration, effectively decoupling the mechanisms for
discovery from registration and implementation. I no longer need to be aware of the "EventLogServic e" class. I just simply need to
be aware that I want to use, say, the default provider. Provider service registration, in ASP.NET 2.0, happens to use xml
configuration and a static class as the entry point for service discovery at runtime.
Does that clear it up?
--
Dave Sexton
"dotNeter" <Bu************ @gmail.comwrote in message news:11******** **************@ i42g2000cwa.goo glegroups.com.. .
>A mechanism for discovery and consumption?
Interfaces are enough for exposing what consumers can do, then why
still need discovery?
I'm a little confused. Is it the reason that there is no real provider?
I guess.
Dave Sexton wrote:
>Hi,
Thanks for the links, but the ASP.NET provider pattern is an example of an abstract base class with configuration. I was hoping
there was documentation of a component-based design pattern, one that did not use xml configuration as a part of the solution,
named, "Provider". I guess there is none.
I assume, somewhat like that used by ASP.NET, the pattern consists of an abstract base class that is the contract being
"provided",
a concrete implementation of that contract, a strong-typed collection for that contract, an abstract service class that exposes
that
collection as a property and a default "provider" as a property, and a concrete implementation of the service class. The service
could also be an interface implementation, which is usually how services are exposed to consumers through a provider.
Sound good or have I described a different pattern altogether?
The goal of the pattern, IMO as I stated in my previous post, is to decouple a service's implementation with the mechanisms for
discovery and consumption. I guess "mechanisms " is a pretty lose term and that view, if accurate, would explain why there is no
definitive "Provider" pattern.
--
Dave Sexton
"dotNeter" <Bu************ @gmail.comwrote in message news:11******** *************@i 3g2000cwc.googl egroups.com...
Very appreciated for your detailed explanation.
Yes, I had a misunderstandin g. Service pattern decouples the service
prodiver and the consumer. And the *CONTACT* is the key point which
maintains the interop between the service and the consumer.
I don't know if the following links referring to MS Provider pattern
are the desired stuffs, see,
http://msdn.microsoft.com/library/de...sp02182004.asp
http://msdn.microsoft.com/library/de...sp04212004.asp
Dave Sexton wrote:
Hi,
The services, talked here, are things used in IServiceContain er,
IServiceProvide r, etc.
The term "Service" and "Provider", as in IServiceProvide r, refer to specific design patterns (as does "Container" , which is
self-explanatory IMO).
ServiceInterfa ce pattern:
http://patternshare.org/default.aspx...rviceInterface
The provider pattern decouples a service's implementation with the mechanisms for discovery and consumption. I can't find a
reference to this pattern on patternshare.or g. Maybe someone else has links they could mention.
In my opinion, everything can be a service, and a service is generally
used for providing specific features for service consumers, at design
time.
Many things that aren't commonly referred to as services can be thought of as services, but actually referring to them as
services
would create ambiguity when used out of context. For instance, you don't normally call an object's methods, "services" unless
you
are creating a logical design. The term "service" is probably overused anyway, but here we are referring to a specific design
pattern.
You can also use these design patterns, as well as the actual interfaces, at runtime. From the perspective of the VS.NET
development team, their application uses them at runtime. You could use these patterns as well in your own applications. You
get
some basic support for services in your own applications just by deriving a class from System.Componen tModel.Componen t. Web
services are another example of services being consumed at runtime. There are many, many more examples.
But, I think the cnsumers must completely know all aspects of
that service. This sounds not good, and breaks the decoupling rule.
I don't think a consumer must know all aspects of a service that it consumes, otherwise it would break encapsulation. A
service
could very well implement multiple service interfaces if they must share data. The consumer need only be concerned with the
interface on which it's performing it's work.
As for breaking the "decoupling rule", I think the service pattern intends to do just the opposite by creating a loose
coupling
between the service implementation and the applications that use it, unless you are referring to a rule of which I'm unaware.
I'm
referring to the notion that loose coupling of components is generally better.
So how to understand the role of Service, in a software engineering
perspective.
Thx in advance.
Review design patterns and gather experience if you don't understand them.
--
Dave Sexton
Whoa! So that it is. This makes perfect sense.
thx you very much.
Dave Sexton wrote:
Hi,
I see a "provider" as providing one or more services so that services can be "discovered " at runtime, instead of just directly
accessing a class that implements a service.
For instance, say that I know of a service interface that exposes methods for logging. The interface provides a loose coupling
between an implementation of logging, which can be file-based or use the event log service (another service), and the consumer.
However, as a consumer I would still need to acquire an implementation of that interface. If I know of a class named,
"EventLogServic e" that implements the logging service interface I could create an instance of that class, however the provider
pattern would enable a different mechanism for discovery. Using a provider I'm able to discover services at runtime based on a
specific service interface without being aware of the mechanisms for service registration, effectively decoupling the mechanisms for
discovery from registration and implementation. I no longer need to be aware of the "EventLogServic e" class. I just simply need to
be aware that I want to use, say, the default provider. Provider service registration, in ASP.NET 2.0, happens to use xml
configuration and a static class as the entry point for service discovery at runtime.
Does that clear it up?
--
Dave Sexton
"dotNeter" <Bu************ @gmail.comwrote in message news:11******** **************@ i42g2000cwa.goo glegroups.com.. .
A mechanism for discovery and consumption?
Interfaces are enough for exposing what consumers can do, then why
still need discovery?
I'm a little confused. Is it the reason that there is no real provider?
I guess.
Dave Sexton wrote:
Hi,
Thanks for the links, but the ASP.NET provider pattern is an example of an abstract base class with configuration. I was hoping
there was documentation of a component-based design pattern, one that did not use xml configuration as a part of the solution,
named, "Provider". I guess there is none.
I assume, somewhat like that used by ASP.NET, the pattern consists of an abstract base class that is the contract being
"provided",
a concrete implementation of that contract, a strong-typed collection for that contract, an abstract service class that exposes
that
collection as a property and a default "provider" as a property, and a concrete implementation of the service class. The service
could also be an interface implementation, which is usually how services are exposed to consumers through a provider.
Sound good or have I described a different pattern altogether?
The goal of the pattern, IMO as I stated in my previous post, is to decouple a service's implementation with the mechanisms for
discovery and consumption. I guess "mechanisms " is a pretty lose term and that view, if accurate, would explain why there is no
definitive "Provider" pattern.
--
Dave Sexton
"dotNeter" <Bu************ @gmail.comwrote in message news:11******** *************@i 3g2000cwc.googl egroups.com...
Very appreciated for your detailed explanation.
Yes, I had a misunderstandin g. Service pattern decouples the service
prodiver and the consumer. And the *CONTACT* is the key point which
maintains the interop between the service and the consumer.
I don't know if the following links referring to MS Provider pattern
are the desired stuffs, see,
http://msdn.microsoft.com/library/de...sp02182004.asp
http://msdn.microsoft.com/library/de...sp04212004.asp
Dave Sexton wrote:
Hi,
The services, talked here, are things used in IServiceContain er,
IServiceProvide r, etc.
The term "Service" and "Provider", as in IServiceProvide r, refer to specific design patterns (as does "Container" , which is
self-explanatory IMO).
ServiceInterfac e pattern:
http://patternshare.org/default.aspx...rviceInterface
The provider pattern decouples a service's implementation with the mechanisms for discovery and consumption. I can't find a
reference to this pattern on patternshare.or g. Maybe someone else has links they could mention.
In my opinion, everything can be a service, and a service is generally
used for providing specific features for service consumers, at design
time.
Many things that aren't commonly referred to as services can be thought of as services, but actually referring to them as
services
would create ambiguity when used out of context. For instance, you don't normally call an object's methods, "services" unless
you
are creating a logical design. The term "service" is probably overused anyway, but here we are referring to a specific design
pattern.
You can also use these design patterns, as well as the actual interfaces, at runtime. From the perspective of the VS.NET
development team, their application uses them at runtime. You could use these patterns as well in your own applications. You
get
some basic support for services in your own applications just by deriving a class from System.Componen tModel.Componen t. Web
services are another example of services being consumed at runtime. There are many, many more examples.
But, I think the cnsumers must completely know all aspects of
that service. This sounds not good, and breaks the decoupling rule.
I don't think a consumer must know all aspects of a service that it consumes, otherwise it would break encapsulation. A
service
could very well implement multiple service interfaces if they must share data. The consumer need only be concerned with the
interface on which it's performing it's work.
As for breaking the "decoupling rule", I think the service pattern intends to do just the opposite by creating a loose
coupling
between the service implementation and the applications that use it, unless you are referring to a rule of which I'm unaware.
I'm
referring to the notion that loose coupling of components is generally better.
So how to understand the role of Service, in a software engineering
perspective.
Thx in advance.
Review design patterns and gather experience if you don't understand them.
--
Dave Sexton
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: yensao |
last post by:
Hi,
I have a hard time to understand difference and similarities between
Relational database model and the Object-Oriented model. Can somebody
help me with this?
Thank you in advance.
Yensao
|
by: php newbie |
last post by:
Hello,
I am trying to load a simple tab-delimited data file to SQL Server. I
created a format file to go with it, since the data file differs from
the destination table in number of columns.
When I execute the query, I get an error saying that only sysadmin or
bulkadmin roles are allowed to use the BULK INSERT statement. So, I
proceeded with the Enterprise Manager to grant myself those roles.
However, I could not find sysadmin or...
|
by: Thom Little |
last post by:
I seem to (once again) be missing something pretty basic.
I am running under Windows XP Professional Service Pack 1 with all Hotfixes
installed and Visual Studio .NET 2003 in Debug mode.
The following reports "You have the >Administrator< role."
using System.Security.Principal ;
using System.Security.Permissions ;
|
by: Jon Skeet [C# MVP] |
last post by:
I've got a web service where different methods require different roles,
and I'm trying to enforce that now.
I've worked out *one* way of doing things, using
PrincipalPermissionAttribute - but that ends up with a response of 500
rather than a 403.
What's the best way of demanding roles for execution of individual web
methods? Obviously I can write a CheckRole method which sets the
response code appropriately, but then if I'm executing...
|
by: Ken Varn |
last post by:
I am configuring my web service with Web.config using windows
authentication. I want to limit the web service permissions by using the
allow / deny roles authorization. I have added the following in my
web.config:
<authentication mode="Windows" />
<authorization>
<allow roles="Administrators"/> <!-- I am assuming this can be
specified as a windows user group -->
<deny users="*" />
| | |
by: Spondishy |
last post by:
Hi,
I'm just getting into asp.net 2 c# using the login and registration
controls. I have a role called publisher and want the user adding to
that role when they register and send an email to say they have
registered.
Do I just add the code to create the role in the
CreateUserWizard_CreatedUser method? Is there a better way?
|
by: Smokey Grindle |
last post by:
Can you use asp.net's membership and role provider sevices inside a web
service for authentication? I am trying to find a way to reduce coding.. and
that seems like it would be a good fit to do simple authentication (a user
would login using a login method and create a session that way) thanks!
|
by: Khafancoder |
last post by:
Hi ,
i'm developing a permission-based win application
there is one Permission for each possible Action in db & each Role
has
some Permissions
and a custom authentication system is implemented for identifying
users and their roles
|
by: Anthony Smith |
last post by:
I have a user object that is set when a user logs in. There are also
permissions that I get about the user from a web service. Currently I
take the results from those web services and store them as XML in the
user object so I can parse it when I need to look at them. I wanted to
turn the xml permissions into ROle objects, but does that mean that my
User class needs to make reference to the Role class?
User class example
class User{
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
| | |
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert into image.
Globals.ThisAddIn.Application.ActiveDocument.Select();...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols.
I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
| | |
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| |
