In WAA 1.9 there is an environment variable named WAA_DEVMODE in the 
StartWAA.bat file.
With "SET WAA_DEVMODE=ON" any loaded DLL would be unloaded during a new 
PBUILD and then the new updated DLL would be loaded.

In WAA 2.0 that environment variable is not supported.
Hence, the DLL has to be unloaded manually from a small scrolling 
drop-down list, then PBUILD has to be run and then the new DLL has to be 
loaded manually.

Is there some way, the 2.0 DLL PBUILD process can be automated to work 
like 1.9?
Please do not advise me to use the workbench.
Thank you for your comments.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Hey Al,

It looks like there is a misunderstanding of WAA_DEVMODE.

When the environment WAA_DEVMODE is set then the WAA creates
a copy of the package dll and loads the copy instead of the
original. Before a request is routed to the WAA package function
and if a newer version of the package exists, then the copy
is unloaded and a copy of the new version is loaded instead. So the 
original WAA package is not loaded any time.

The WAA 2.0 behaves exactly as the WAA in version 1.9. At least this is 
our understanding and intention.

 > Please do not advise me to use the workbench.
Why? This is not necessary for your issue but working with the Workbench 
is not a bad idea.

For clarification and in case you still encounter the issue while
developing and debugging WAA packages, please get in contact with
support@alaska-software.com.

Kind regards,

Frank

On 12.03.2017 21:38, Al Wilson wrote:
> In WAA 1.9 there is an environment variable named WAA_DEVMODE in the
> StartWAA.bat file.
> With "SET WAA_DEVMODE=ON" any loaded DLL would be unloaded during a new
> PBUILD and then the new updated DLL would be loaded.
>
> In WAA 2.0 that environment variable is not supported.
> Hence, the DLL has to be unloaded manually from a small scrolling
> drop-down list, then PBUILD has to be run and then the new DLL has to be
> loaded manually.
>
> Is there some way, the 2.0 DLL PBUILD process can be automated to work
> like 1.9?
> Please do not advise me to use the workbench.
> Thank you for your comments.
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>

Thank you, Frank, for explaining WAA_DEVMODE.

My observation is that PBUILD in 2.0 does not behave the same as 1.9.

If I were to adopt the workbench then my system which has worked 
extemely well for the past 17 years would need to be abandoned.
I do not see a benefit in that course of action.

Why is WAA_DEVMODE not supported in 2.0?

On 3/23/17 7:46 AM, Frank Grossheinrich wrote:
> Hey Al,
>
> It looks like there is a misunderstanding of WAA_DEVMODE.
>
> When the environment WAA_DEVMODE is set then the WAA creates
> a copy of the package dll and loads the copy instead of the
> original. Before a request is routed to the WAA package function
> and if a newer version of the package exists, then the copy
> is unloaded and a copy of the new version is loaded instead. So the
> original WAA package is not loaded any time.
>
> The WAA 2.0 behaves exactly as the WAA in version 1.9. At least this is
> our understanding and intention.
>
>> Please do not advise me to use the workbench.
> Why? This is not necessary for your issue but working with the Workbench
> is not a bad idea.
>
> For clarification and in case you still encounter the issue while
> developing and debugging WAA packages, please get in contact with
> support@alaska-software.com.
>
> Kind regards,
>
> Frank
>
> On 12.03.2017 21:38, Al Wilson wrote:
>> In WAA 1.9 there is an environment variable named WAA_DEVMODE in the
>> StartWAA.bat file.
>> With "SET WAA_DEVMODE=ON" any loaded DLL would be unloaded during a new
>> PBUILD and then the new updated DLL would be loaded.
>>
>> In WAA 2.0 that environment variable is not supported.
>> Hence, the DLL has to be unloaded manually from a small scrolling
>> drop-down list, then PBUILD has to be run and then the new DLL has to be
>> loaded manually.
>>
>> Is there some way, the 2.0 DLL PBUILD process can be automated to work
>> like 1.9?
>> Please do not advise me to use the workbench.
>> Thank you for your comments.
>>
>> ---
>> This email has been checked for viruses by Avast antivirus software.
>> https://www.avast.com/antivirus
>>
>

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Hey Al,

hope I was not that misleading ... but apparently I was: WAA_DEVMODE is 
definitely working. I took the time and tested it personally. So it is 
still there and usable! And works as I described. I started WAA with the 
environment variable set to ON, changed some code of one of the sample 
packages, built the package and called the WAA function again and all is 
in proper shape. WAA internally unloaded the ~package, copied the new 
built DLL to ~package a did load it again and fired its code.

Please check on your own: as soon you run WAA in WAA_DEVMODE and you 
load the package you will get a copy of the DLL in the very same 
directory prefixed with a tilde (~). If not, you are not running in 
WAA_DEVMODE.

So I would take a look at the DLL (the package) itself. Can you 
dynamically unload it? Does the package load other DLLs? Can those be 
unloaded? You get the picture?

If you are still stuck, please get in contact with my colleagues at 
Technical Support. They are extremely interested in that issue.

Regards, Frank

On 23.03.2017 16:47, Al Wilson wrote:
> Thank you, Frank, for explaining WAA_DEVMODE.
>
> My observation is that PBUILD in 2.0 does not behave the same as 1.9.
>
> If I were to adopt the workbench then my system which has worked
> extemely well for the past 17 years would need to be abandoned.
> I do not see a benefit in that course of action.
>
> Why is WAA_DEVMODE not supported in 2.0?
>
> On 3/23/17 7:46 AM, Frank Grossheinrich wrote:
>> Hey Al,
>>
>> It looks like there is a misunderstanding of WAA_DEVMODE.
>>
>> When the environment WAA_DEVMODE is set then the WAA creates
>> a copy of the package dll and loads the copy instead of the
>> original. Before a request is routed to the WAA package function
>> and if a newer version of the package exists, then the copy
>> is unloaded and a copy of the new version is loaded instead. So the
>> original WAA package is not loaded any time.
>>
>> The WAA 2.0 behaves exactly as the WAA in version 1.9. At least this is
>> our understanding and intention.
>>
>>> Please do not advise me to use the workbench.
>> Why? This is not necessary for your issue but working with the Workbench
>> is not a bad idea.
>>
>> For clarification and in case you still encounter the issue while
>> developing and debugging WAA packages, please get in contact with
>> support@alaska-software.com.
>>
>> Kind regards,
>>
>> Frank
>>
>> On 12.03.2017 21:38, Al Wilson wrote:
>>> In WAA 1.9 there is an environment variable named WAA_DEVMODE in the
>>> StartWAA.bat file.
>>> With "SET WAA_DEVMODE=ON" any loaded DLL would be unloaded during a new
>>> PBUILD and then the new updated DLL would be loaded.
>>>
>>> In WAA 2.0 that environment variable is not supported.
>>> Hence, the DLL has to be unloaded manually from a small scrolling
>>> drop-down list, then PBUILD has to be run and then the new DLL has to be
>>> loaded manually.
>>>
>>> Is there some way, the 2.0 DLL PBUILD process can be automated to work
>>> like 1.9?
>>> Please do not advise me to use the workbench.
>>> Thank you for your comments.
>>>
>>> ---
>>> This email has been checked for viruses by Avast antivirus software.
>>> https://www.avast.com/antivirus
>>>
>>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>

Hi Frank:

WAA_DEVMODE is set to on.
WAA loads eleven DLLs.
There are no prefixed ~DLL copies created in the same directory.
Any DLL can be dynamically unloaded and reloaded.
Each DLL loads a library file via #pragma in the _Register(oPackage) 
function

Why does the 2.0 documentation say that WAA_DEVMODE is not supported?
Is the WAA behaviour directory-specific?

I have also sent this message to Technical Support.

On 3/24/17 7:03 AM, Frank Grossheinrich wrote:
> Hey Al,
>
> hope I was not that misleading ... but apparently I was: WAA_DEVMODE is
> definitely working. I took the time and tested it personally. So it is
> still there and usable! And works as I described. I started WAA with the
> environment variable set to ON, changed some code of one of the sample
> packages, built the package and called the WAA function again and all is
> in proper shape. WAA internally unloaded the ~package, copied the new
> built DLL to ~package a did load it again and fired its code.
>
> Please check on your own: as soon you run WAA in WAA_DEVMODE and you
> load the package you will get a copy of the DLL in the very same
> directory prefixed with a tilde (~). If not, you are not running in
> WAA_DEVMODE.
>
> So I would take a look at the DLL (the package) itself. Can you
> dynamically unload it? Does the package load other DLLs? Can those be
> unloaded? You get the picture?
>
> If you are still stuck, please get in contact with my colleagues at
> Technical Support. They are extremely interested in that issue.
>
> Regards, Frank
>
> On 23.03.2017 16:47, Al Wilson wrote:
>> Thank you, Frank, for explaining WAA_DEVMODE.
>>
>> My observation is that PBUILD in 2.0 does not behave the same as 1.9.
>>
>> If I were to adopt the workbench then my system which has worked
>> extemely well for the past 17 years would need to be abandoned.
>> I do not see a benefit in that course of action.
>>
>> Why is WAA_DEVMODE not supported in 2.0?
>>
>> On 3/23/17 7:46 AM, Frank Grossheinrich wrote:
>>> Hey Al,
>>>
>>> It looks like there is a misunderstanding of WAA_DEVMODE.
>>>
>>> When the environment WAA_DEVMODE is set then the WAA creates
>>> a copy of the package dll and loads the copy instead of the
>>> original. Before a request is routed to the WAA package function
>>> and if a newer version of the package exists, then the copy
>>> is unloaded and a copy of the new version is loaded instead. So the
>>> original WAA package is not loaded any time.
>>>
>>> The WAA 2.0 behaves exactly as the WAA in version 1.9. At least this is
>>> our understanding and intention.
>>>
>>>> Please do not advise me to use the workbench.
>>> Why? This is not necessary for your issue but working with the Workbench
>>> is not a bad idea.
>>>
>>> For clarification and in case you still encounter the issue while
>>> developing and debugging WAA packages, please get in contact with
>>> support@alaska-software.com.
>>>
>>> Kind regards,
>>>
>>> Frank
>>>
>>> On 12.03.2017 21:38, Al Wilson wrote:
>>>> In WAA 1.9 there is an environment variable named WAA_DEVMODE in the
>>>> StartWAA.bat file.
>>>> With "SET WAA_DEVMODE=ON" any loaded DLL would be unloaded during a new
>>>> PBUILD and then the new updated DLL would be loaded.
>>>>
>>>> In WAA 2.0 that environment variable is not supported.
>>>> Hence, the DLL has to be unloaded manually from a small scrolling
>>>> drop-down list, then PBUILD has to be run and then the new DLL has
>>>> to be
>>>> loaded manually.
>>>>
>>>> Is there some way, the 2.0 DLL PBUILD process can be automated to work
>>>> like 1.9?
>>>> Please do not advise me to use the workbench.
>>>> Thank you for your comments.
>>>>
>>>> ---
>>>> This email has been checked for viruses by Avast antivirus software.
>>>> https://www.avast.com/antivirus
>>>>
>>>
>>
>> ---
>> This email has been checked for viruses by Avast antivirus software.
>> https://www.avast.com/antivirus
>>
>

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus