Hello All....
I have a question... i have two Windows apps (one UI, and one service)
which use a common DLL that hands out database results and such to the
two apps. The DLL always connects to the DB the same way, regardless of
which app calls it. So i wanted to store info in the config file for
the DLL... only to find out it wont read that file at all. I am using
VS2005.
Searching online, i find that DLLs WILL NOT read their own configs, but
only of the exe which loaded them, and that basically, the only way to
store settings for the DLL itself, independent of the calling exe, is
to roll my own configuration/settings engine.
*Is that seriously true??* That seems a major flaw, as the whole point
of the DLL is to be common, and hide all the settings from the exes,
which is why i wanted it to have its own config file instead of having
to add the same settings over and over to every app that calls that
DLL.
Thanks in advance.
CheerZ.
8  1888 
Well, it's really not that difficult to roll your own configuration class. I
did for VS 2003 and continue to use it. If you consider it, the intrinsic
one is a bit limited anyway. You can even implement
IConfigurationSectionHandler. However, I didn't, I just rolled it from
scratch. It behaves very similarly to the instrinsic one but has more
capabilites.
Steve
<aa****@yahoo.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.com...
Hello All....
I have a question... i have two Windows apps (one UI, and one service)
which use a common DLL that hands out database results and such to the
two apps. The DLL always connects to the DB the same way, regardless of
which app calls it. So i wanted to store info in the config file for
the DLL... only to find out it wont read that file at all. I am using
VS2005.
Searching online, i find that DLLs WILL NOT read their own configs, but
only of the exe which loaded them, and that basically, the only way to
store settings for the DLL itself, independent of the calling exe, is
to roll my own configuration/settings engine.
*Is that seriously true??* That seems a major flaw, as the whole point
of the DLL is to be common, and hide all the settings from the exes,
which is why i wanted it to have its own config file instead of having
to add the same settings over and over to every app that calls that
DLL.
Thanks in advance.
CheerZ.
If you don't want the settings to be changed per application, why are you
storing them in a configuration file?
--
HTH,
Kevin Spencer
Microsoft MVP
Chicken Salad Shooter http://unclechutney.blogspot.com
A man, a plan, a canal, a palindrome that has.. oh, never mind.
<aa****@yahoo.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.com...
Hello All....
I have a question... i have two Windows apps (one UI, and one service)
which use a common DLL that hands out database results and such to the
two apps. The DLL always connects to the DB the same way, regardless of
which app calls it. So i wanted to store info in the config file for
the DLL... only to find out it wont read that file at all. I am using
VS2005.
Searching online, i find that DLLs WILL NOT read their own configs, but
only of the exe which loaded them, and that basically, the only way to
store settings for the DLL itself, independent of the calling exe, is
to roll my own configuration/settings engine.
*Is that seriously true??* That seems a major flaw, as the whole point
of the DLL is to be common, and hide all the settings from the exes,
which is why i wanted it to have its own config file instead of having
to add the same settings over and over to every app that calls that
DLL.
Thanks in advance.
CheerZ.
Well, I want them to be easily and quickly changeable without having to
either recompile/redistribute or having to delve into the registry... that
is, a la "config file".
But I want them in <ONEcentral place, that is, in the DLL.. the whole
point of the DLL is a central unit of shared "code". So that they do not
need to be changed in every application that uses the DLL. Some things
differ from app-to-app... but these settings are common to all apps and are
meant to be hidden in the DLL.
I have rolled the beginnings of my own configuration engine, as Steve did,
so its taken care of, it just seems strange is all.
"Kevin Spencer" <sp**@uce.govwrote in message
news:uV**************@TK2MSFTNGP03.phx.gbl...
If you don't want the settings to be changed per application, why are you
storing them in a configuration file?
--
HTH,
Kevin Spencer
Microsoft MVP
Chicken Salad Shooter
http://unclechutney.blogspot.com
A man, a plan, a canal, a palindrome that has.. oh, never mind.
<aa****@yahoo.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.com...
>Hello All....
I have a question... i have two Windows apps (one UI, and one service)
which use a common DLL that hands out database results and such to the
two apps. The DLL always connects to the DB the same way, regardless of
which app calls it. So i wanted to store info in the config file for
the DLL... only to find out it wont read that file at all. I am using
VS2005.
Searching online, i find that DLLs WILL NOT read their own configs, but
only of the exe which loaded them, and that basically, the only way to
store settings for the DLL itself, independent of the calling exe, is
to roll my own configuration/settings engine.
*Is that seriously true??* That seems a major flaw, as the whole point
of the DLL is to be common, and hide all the settings from the exes,
which is why i wanted it to have its own config file instead of having
to add the same settings over and over to every app that calls that
DLL.
Thanks in advance.
CheerZ.
How about using string resources in the DLL?
--
HTH,
Kevin Spencer
Microsoft MVP
Short Order Coder http://unclechutney.blogspot.com
What You Seek Is What You Get
"Arthur Dent" <hi*********************@yahoo.comwrote in message
news:C5**********************************@microsof t.com...
Well, I want them to be easily and quickly changeable without having to
either recompile/redistribute or having to delve into the registry... that
is, a la "config file".
But I want them in <ONEcentral place, that is, in the DLL.. the whole
point of the DLL is a central unit of shared "code". So that they do not
need to be changed in every application that uses the DLL. Some things
differ from app-to-app... but these settings are common to all apps and
are meant to be hidden in the DLL.
I have rolled the beginnings of my own configuration engine, as Steve did,
so its taken care of, it just seems strange is all.
"Kevin Spencer" <sp**@uce.govwrote in message
news:uV**************@TK2MSFTNGP03.phx.gbl...
>If you don't want the settings to be changed per application, why are you
storing them in a configuration file?
--
HTH,
Kevin Spencer
Microsoft MVP
Chicken Salad Shooter
http://unclechutney.blogspot.com
A man, a plan, a canal, a palindrome that has.. oh, never mind.
<aa****@yahoo.comwrote in message
news:11**********************@b28g2000cwb.googleg roups.com...
>>Hello All....
I have a question... i have two Windows apps (one UI, and one service)
which use a common DLL that hands out database results and such to the
two apps. The DLL always connects to the DB the same way, regardless of
which app calls it. So i wanted to store info in the config file for
the DLL... only to find out it wont read that file at all. I am using
VS2005.
Searching online, i find that DLLs WILL NOT read their own configs, but
only of the exe which loaded them, and that basically, the only way to
store settings for the DLL itself, independent of the calling exe, is
to roll my own configuration/settings engine.
*Is that seriously true??* That seems a major flaw, as the whole point
of the DLL is to be common, and hide all the settings from the exes,
which is why i wanted it to have its own config file instead of having
to add the same settings over and over to every app that calls that
DLL.
Thanks in advance.
CheerZ.
Yes but it depends what your DLL does and someone else would want distinct
settings.
But I remember to have seen once that you can actually reference a config
file from within a config file. It would allow to accomodate both scenarios
:
- each application uses its own unique file, they have each their own
private settings
- if their config file references a single common config file, they can then
share those settings (all or just some of them)
After doing a small research I came accross : http://msdn.microsoft.com/library/de...ngsElement.asp
The file attrribute seems to be the mechanism that references this common
file. You may want to give this a try...
--
Patrice
"Arthur Dent" <hi*********************@yahoo.coma écrit dans le message de
news: C5**********************************@microsoft.com...
Well, I want them to be easily and quickly changeable without having to
either recompile/redistribute or having to delve into the registry... that
is, a la "config file".
But I want them in <ONEcentral place, that is, in the DLL.. the whole
point of the DLL is a central unit of shared "code". So that they do not
need to be changed in every application that uses the DLL. Some things
differ from app-to-app... but these settings are common to all apps and
are meant to be hidden in the DLL.
I have rolled the beginnings of my own configuration engine, as Steve did,
so its taken care of, it just seems strange is all.
"Kevin Spencer" <sp**@uce.govwrote in message
news:uV**************@TK2MSFTNGP03.phx.gbl...
>If you don't want the settings to be changed per application, why are you
storing them in a configuration file?
--
HTH,
Kevin Spencer
Microsoft MVP
Chicken Salad Shooter
http://unclechutney.blogspot.com
A man, a plan, a canal, a palindrome that has.. oh, never mind.
<aa****@yahoo.comwrote in message
news:11**********************@b28g2000cwb.googleg roups.com...
>>Hello All....
I have a question... i have two Windows apps (one UI, and one service)
which use a common DLL that hands out database results and such to the
two apps. The DLL always connects to the DB the same way, regardless of
which app calls it. So i wanted to store info in the config file for
the DLL... only to find out it wont read that file at all. I am using
VS2005.
Searching online, i find that DLLs WILL NOT read their own configs, but
only of the exe which loaded them, and that basically, the only way to
store settings for the DLL itself, independent of the calling exe, is
to roll my own configuration/settings engine.
*Is that seriously true??* That seems a major flaw, as the whole point
of the DLL is to be common, and hide all the settings from the exes,
which is why i wanted it to have its own config file instead of having
to add the same settings over and over to every app that calls that
DLL.
Thanks in advance.
CheerZ.
Well, here's what I did.
I wrote an AppConfiguration dll. The AppInit class will take a path and
filename in its constructor. AppInit can handle any number of sections in
it. So:
<configuration>
<appSettings>
<add key="mynewkey" value="mynewvalue" />
<appSettings/>
<yetAnotherSection>
<add key="yetanotherkey" value="yetanothervalue" />
<yetAnotherSection/>
<configuration/>
AppInit reads in the above file in its proper hiearchy. To get the value for
"yetanotherkey", the code would be:
appInit.Get("sectionName", "yetanotherkey")
To get all the section names:
appInit.GetKeys()
To get all the keys for a particular section:
appInit.GetKeys("sectionName")
These both return a string array. And, because you can pass a fully
qualified filename to the constructor of AppInit, you can open any file with
it. The file name doesn't have to be myApp.exe.config. It could be a
completely different configuration file for different purposes, say a
..dll???
This is exactly what I do. I have configuration settings that are not
handled by the .exe but a .dll that the .exe uses.
AppInit also watches its file for changes and raises an event if the file
changes from some external source via a FileSystemWatcher.
I have a friend in the same industry as I am, that works at a different
place than me that took a similar approach to the configuration files
scenario, so my thinking wasn't too terribly screwed up... :)
Steve
"Patrice" <sc****@chez.comwrote in message
news:ei**************@TK2MSFTNGP03.phx.gbl...
Yes but it depends what your DLL does and someone else would want distinct
settings.
But I remember to have seen once that you can actually reference a config
file from within a config file. It would allow to accomodate both
scenarios :
- each application uses its own unique file, they have each their own
private settings
- if their config file references a single common config file, they can
then share those settings (all or just some of them)
After doing a small research I came accross :
http://msdn.microsoft.com/library/de...ngsElement.asp
The file attrribute seems to be the mechanism that references this common
file. You may want to give this a try...
--
Patrice
"Arthur Dent" <hi*********************@yahoo.coma écrit dans le message
de news: C5**********************************@microsoft.com...
>Well, I want them to be easily and quickly changeable without having to
either recompile/redistribute or having to delve into the registry...
that is, a la "config file".
But I want them in <ONEcentral place, that is, in the DLL.. the whole
point of the DLL is a central unit of shared "code". So that they do not
need to be changed in every application that uses the DLL. Some things
differ from app-to-app... but these settings are common to all apps and
are meant to be hidden in the DLL.
I have rolled the beginnings of my own configuration engine, as Steve
did, so its taken care of, it just seems strange is all.
"Kevin Spencer" <sp**@uce.govwrote in message
news:uV**************@TK2MSFTNGP03.phx.gbl...
>>If you don't want the settings to be changed per application, why are
you storing them in a configuration file?
--
HTH,
Kevin Spencer
Microsoft MVP
Chicken Salad Shooter
http://unclechutney.blogspot.com
A man, a plan, a canal, a palindrome that has.. oh, never mind.
<aa****@yahoo.comwrote in message
news:11**********************@b28g2000cwb.google groups.com...
Hello All....
I have a question... i have two Windows apps (one UI, and one service)
which use a common DLL that hands out database results and such to the
two apps. The DLL always connects to the DB the same way, regardless of
which app calls it. So i wanted to store info in the config file for
the DLL... only to find out it wont read that file at all. I am using
VS2005.
Searching online, i find that DLLs WILL NOT read their own configs, but
only of the exe which loaded them, and that basically, the only way to
store settings for the DLL itself, independent of the calling exe, is
to roll my own configuration/settings engine.
*Is that seriously true??* That seems a major flaw, as the whole point
of the DLL is to be common, and hide all the settings from the exes,
which is why i wanted it to have its own config file instead of having
to add the same settings over and over to every app that calls that
DLL.
Thanks in advance.
CheerZ.
I would likely still prefer the other approach if it works...
The entry point is the application config file but you can choose for each
setting if the value is specific to the application or given by a shared
configuration file...
--
Patrice
"Steve Long" <St**********@NoSpam.coma écrit dans le message de news:
O$**************@TK2MSFTNGP03.phx.gbl...
Well, here's what I did.
I wrote an AppConfiguration dll. The AppInit class will take a path and
filename in its constructor. AppInit can handle any number of sections in
it. So:
<configuration>
<appSettings>
<add key="mynewkey" value="mynewvalue" />
<appSettings/>
<yetAnotherSection>
<add key="yetanotherkey" value="yetanothervalue" />
<yetAnotherSection/>
<configuration/>
AppInit reads in the above file in its proper hiearchy. To get the value
for "yetanotherkey", the code would be:
appInit.Get("sectionName", "yetanotherkey")
To get all the section names:
appInit.GetKeys()
To get all the keys for a particular section:
appInit.GetKeys("sectionName")
These both return a string array. And, because you can pass a fully
qualified filename to the constructor of AppInit, you can open any file
with it. The file name doesn't have to be myApp.exe.config. It could be a
completely different configuration file for different purposes, say a
.dll???
This is exactly what I do. I have configuration settings that are not
handled by the .exe but a .dll that the .exe uses.
AppInit also watches its file for changes and raises an event if the file
changes from some external source via a FileSystemWatcher.
I have a friend in the same industry as I am, that works at a different
place than me that took a similar approach to the configuration files
scenario, so my thinking wasn't too terribly screwed up... :)
Steve
"Patrice" <sc****@chez.comwrote in message
news:ei**************@TK2MSFTNGP03.phx.gbl...
>Yes but it depends what your DLL does and someone else would want
distinct settings.
But I remember to have seen once that you can actually reference a config
file from within a config file. It would allow to accomodate both
scenarios :
- each application uses its own unique file, they have each their own
private settings
- if their config file references a single common config file, they can
then share those settings (all or just some of them)
After doing a small research I came accross :
http://msdn.microsoft.com/library/de...ngsElement.asp
The file attrribute seems to be the mechanism that references this common
file. You may want to give this a try...
--
Patrice
"Arthur Dent" <hi*********************@yahoo.coma écrit dans le message
de news: C5**********************************@microsoft.com...
>>Well, I want them to be easily and quickly changeable without having to
either recompile/redistribute or having to delve into the registry...
that is, a la "config file".
But I want them in <ONEcentral place, that is, in the DLL.. the whole
point of the DLL is a central unit of shared "code". So that they do not
need to be changed in every application that uses the DLL. Some things
differ from app-to-app... but these settings are common to all apps and
are meant to be hidden in the DLL.
I have rolled the beginnings of my own configuration engine, as Steve
did, so its taken care of, it just seems strange is all.
"Kevin Spencer" <sp**@uce.govwrote in message
news:uV**************@TK2MSFTNGP03.phx.gbl...
If you don't want the settings to be changed per application, why are
you storing them in a configuration file?
--
HTH,
Kevin Spencer
Microsoft MVP
Chicken Salad Shooter
http://unclechutney.blogspot.com
A man, a plan, a canal, a palindrome that has.. oh, never mind.
<aa****@yahoo.comwrote in message
news:11**********************@b28g2000cwb.googl egroups.com...
Hello All....
>
I have a question... i have two Windows apps (one UI, and one service)
which use a common DLL that hands out database results and such to the
two apps. The DLL always connects to the DB the same way, regardless
of
which app calls it. So i wanted to store info in the config file for
the DLL... only to find out it wont read that file at all. I am using
VS2005.
>
Searching online, i find that DLLs WILL NOT read their own configs,
but
only of the exe which loaded them, and that basically, the only way to
store settings for the DLL itself, independent of the calling exe, is
to roll my own configuration/settings engine.
>
*Is that seriously true??* That seems a major flaw, as the whole point
of the DLL is to be common, and hide all the settings from the exes,
which is why i wanted it to have its own config file instead of having
to add the same settings over and over to every app that calls that
DLL.
>
Thanks in advance.
CheerZ.
>
This is very similar to what I did, though I took a little more technical
approach in terms of how the settings are referenced, using a path syntax
instead.
so for example my function looks like
GetSetting(Path as String, Optional DefaultValue as Object = Nothing) As
Object
It then uses XmlDocument.SelectSingleNode with that path, so that you can
store any level of sections/subsections/values hierarchy in the file.
Its still a baby of code, and not very robust yet, but like Steve's, it
takes in a filename, so you can pass it whatever file you want. Even have
multiple files for one project for different uses.
It will also have a version using SelectNodes() so that you can store
multiple settings with the same "key", that is, essentially a setting
collection, which the native App.Config files do not allow.
It works well enough.
"Steve Long" <St**********@NoSpam.comwrote in message
news:O$**************@TK2MSFTNGP03.phx.gbl...
Well, here's what I did.
I wrote an AppConfiguration dll. The AppInit class will take a path and
filename in its constructor. AppInit can handle any number of sections in
it. So:
<configuration>
<appSettings>
<add key="mynewkey" value="mynewvalue" />
<appSettings/>
<yetAnotherSection>
<add key="yetanotherkey" value="yetanothervalue" />
<yetAnotherSection/>
<configuration/>
AppInit reads in the above file in its proper hiearchy. To get the value
for "yetanotherkey", the code would be:
appInit.Get("sectionName", "yetanotherkey")
To get all the section names:
appInit.GetKeys()
To get all the keys for a particular section:
appInit.GetKeys("sectionName")
These both return a string array. And, because you can pass a fully
qualified filename to the constructor of AppInit, you can open any file
with it. The file name doesn't have to be myApp.exe.config. It could be a
completely different configuration file for different purposes, say a
.dll???
This is exactly what I do. I have configuration settings that are not
handled by the .exe but a .dll that the .exe uses.
AppInit also watches its file for changes and raises an event if the file
changes from some external source via a FileSystemWatcher.
I have a friend in the same industry as I am, that works at a different
place than me that took a similar approach to the configuration files
scenario, so my thinking wasn't too terribly screwed up... :)
Steve
"Patrice" <sc****@chez.comwrote in message
news:ei**************@TK2MSFTNGP03.phx.gbl...
>Yes but it depends what your DLL does and someone else would want
distinct settings.
But I remember to have seen once that you can actually reference a config
file from within a config file. It would allow to accomodate both
scenarios :
- each application uses its own unique file, they have each their own
private settings
- if their config file references a single common config file, they can
then share those settings (all or just some of them)
After doing a small research I came accross :
http://msdn.microsoft.com/library/de...ngsElement.asp
The file attrribute seems to be the mechanism that references this common
file. You may want to give this a try...
--
Patrice
"Arthur Dent" <hi*********************@yahoo.coma écrit dans le message
de news: C5**********************************@microsoft.com...
>>Well, I want them to be easily and quickly changeable without having to
either recompile/redistribute or having to delve into the registry...
that is, a la "config file".
But I want them in <ONEcentral place, that is, in the DLL.. the whole
point of the DLL is a central unit of shared "code". So that they do not
need to be changed in every application that uses the DLL. Some things
differ from app-to-app... but these settings are common to all apps and
are meant to be hidden in the DLL.
I have rolled the beginnings of my own configuration engine, as Steve
did, so its taken care of, it just seems strange is all.
"Kevin Spencer" <sp**@uce.govwrote in message
news:uV**************@TK2MSFTNGP03.phx.gbl...
If you don't want the settings to be changed per application, why are
you storing them in a configuration file?
--
HTH,
Kevin Spencer
Microsoft MVP
Chicken Salad Shooter
http://unclechutney.blogspot.com
A man, a plan, a canal, a palindrome that has.. oh, never mind.
<aa****@yahoo.comwrote in message
news:11**********************@b28g2000cwb.googl egroups.com...
Hello All....
>
I have a question... i have two Windows apps (one UI, and one service)
which use a common DLL that hands out database results and such to the
two apps. The DLL always connects to the DB the same way, regardless
of
which app calls it. So i wanted to store info in the config file for
the DLL... only to find out it wont read that file at all. I am using
VS2005.
>
Searching online, i find that DLLs WILL NOT read their own configs,
but
only of the exe which loaded them, and that basically, the only way to
store settings for the DLL itself, independent of the calling exe, is
to roll my own configuration/settings engine.
>
*Is that seriously true??* That seems a major flaw, as the whole point
of the DLL is to be common, and hide all the settings from the exes,
which is why i wanted it to have its own config file instead of having
to add the same settings over and over to every app that calls that
DLL.
>
Thanks in advance.
CheerZ.
>
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Maxim Khesin |
last post by:
I want to have a config file with my python proggie, satisfying the
following requirements:
1) support key->(value, default)
2) simple and intuitive to read and edit
3) easyly readable into a...
|
by: Fuzzyman |
last post by:
There have been a couple of config file 'systems' announced recently,
that focus on building more powerful and complex configuration files.
ConfigObj is a module to enable you to much more *simply*...
|
by: Suresh Gladstone |
last post by:
Hi,
This is a bit with versioning and installation of
the .NET dlls. I want to perform the following,
1. A third party application will be invoking my .NET dll
through COM interop . For this I...
|
by: grs |
last post by:
Can a class library have a app.config file. Reason for asking is that the
microsoft application blocks all read from myApp.exe.config. How can you use
the application blocks if you do not have an...
|
by: Daniel Billingsley |
last post by:
Ok, I wanted to ask this separate from nospam's ridiculous thread in hopes
it could get some honest attention.
VB6 had a some simple and fast mechanisms for retrieving values from basic
text...
|
by: Rich |
last post by:
Hello,
I picked up this example on using the Reflection namespace
for loading forms/classes on the fly at msdn
http://msdn.microsoft.com/library/default.asp?...
|
by: Khodr |
last post by:
Hello,
I am using VS.NET 2003 and vb. I build my application MyApp and it generates
MyApp.exe.config. So now MyApp.exe reads parameters from MyApp.exe.config.
Great and no problem!
I need to...
|
by: Blasting Cap |
last post by:
I am working on a web app that I want to be able to use a separate
config file on, in addition to the web.config file that's already
working in the application.
If I put the following in the...
|
by: dbuchanan |
last post by:
Hello,
(Is this the proper newsgroup?)
=== Background ===
I am building a solution with two projects.
One project is my data access layer which contains my DataSet as an xsd
file. The XSD...
|
by: mmcd79 |
last post by:
I built a VB.net application that makes use of a machine level DB
connection string setting, and a user level starting location setting.
The machine level setting and the default user based...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
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,...
|
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...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
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,...
| |
