On 16.08.2017 04:49, Johnson wrote:
>      VisualD.dll    C:\Program Files (x86)\VisualD\Debug\VisualD.dll    N/A    Yes    Symbols loaded.    C:\Program Files (x86)\VisualD\Debug\VisualD.pdb    229    0.45.1-rc2    12/31/1969 7:00 PM    13FB0000-143C0000*    [8972] devenv.exe
>      VisualD.dll    C:\Program Files (x86)\VisualD\VisualD.dll    N/A    Yes    Cannot find or open the PDB file.        271    0.45.1-rc2    12/31/1969 7:00 PM    18D40000-1904E000*    [8972] devenv.exe
> 
> 
> I was finally able to get it to work. Something is wonky. I think it's when I use a normal VS side by side with the experimental that the experimental can't find the symbols and somehow the registry changes I made got reset.
> 
> So far it is working(I can hit BP's) but it's still basically the same scenario in that I have to completely shut down VS in order to reload visualD. Before I could automate because the normal visual studio instance could stay open... but it seems like it screws up the debugging symbols and such.
> 
> I could try to use another, different exp instance(different registry) but I feel the same problem might occur.
> 
> But I guess it's better than nothing.
> 

Good to hear it (kind of) works now. VS2015 also resets the configuration rather often, so it's good to automate the patching.

I don't have troubles with exchanging the debug DLL while having the normal VS instance running. Maybe you have experimented with registry changes that now cause the debug DLL to be loaded there, too? Reinstalling Visual D should help in that case (though that will trigger rebuilding the user configuration).

I've tried to figure out why both DLLs are actually loaded (it has been bugging me before, too), but could not find the cause yet.

On 16.08.2017 08:32, Rainer Schuetze wrote:
> 
> 
> On 16.08.2017 04:49, Johnson wrote:
>>      VisualD.dll    C:\Program Files (x86)\VisualD\Debug\VisualD.dll N/A    Yes    Symbols loaded.    C:\Program Files (x86)\VisualD\Debug\VisualD.pdb    229    0.45.1-rc2    12/31/1969 7:00 PM    13FB0000-143C0000*    [8972] devenv.exe
>>      VisualD.dll    C:\Program Files (x86)\VisualD\VisualD.dll    N/A Yes    Cannot find or open the PDB file.        271    0.45.1-rc2 12/31/1969 7:00 PM    18D40000-1904E000*    [8972] devenv.exe
>>
>>
>> I was finally able to get it to work. Something is wonky. I think it's when I use a normal VS side by side with the experimental that the experimental can't find the symbols and somehow the registry changes I made got reset.
>>
>> So far it is working(I can hit BP's) but it's still basically the same scenario in that I have to completely shut down VS in order to reload visualD. Before I could automate because the normal visual studio instance could stay open... but it seems like it screws up the debugging symbols and such.
>>
>> I could try to use another, different exp instance(different registry) but I feel the same problem might occur.
>>
>> But I guess it's better than nothing.
>>
> 
> Good to hear it (kind of) works now. VS2015 also resets the configuration rather often, so it's good to automate the patching.
> 
> I don't have troubles with exchanging the debug DLL while having the normal VS instance running. Maybe you have experimented with registry changes that now cause the debug DLL to be loaded there, too? Reinstalling Visual D should help in that case (though that will trigger rebuilding the user configuration).
> 
> I've tried to figure out why both DLLs are actually loaded (it has been bugging me before, too), but could not find the cause yet.

I managed to load the Debug DLL into the "experimental" VS without any (explicit) registry patching:

1. delete HOME%\AppData\Local\Microsoft\VisualStudio\15.0_<id>Exp\privateregistry.bin to make sure to start from scratch

2. copy "c:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\Rainer Schuetze\VisualD" to "%HOME%\AppData\Local\Microsoft\VisualStudio\15.0_<id>Exp\Extensions\Rainer Schuetze\VisualD"

3. replace paths in Extensions\Rainer Schuetze\VisualD\0.45\visuald.pkgdef to point to the debug DLL

4. start "devenv /RootSuffix Exp"

5. enable "Visual D" in the "Extensions and Updates..." dialog

6. restart VS

This even doesn't load the DLL twice for me.

On Wednesday, 16 August 2017 at 06:58:49 UTC, Rainer Schuetze wrote:
>
>
> On 16.08.2017 08:32, Rainer Schuetze wrote:
>> 
>> 
>> On 16.08.2017 04:49, Johnson wrote:
>>>      VisualD.dll    C:\Program Files (x86)\VisualD\Debug\VisualD.dll N/A    Yes    Symbols loaded.
>>>    C:\Program Files (x86)\VisualD\Debug\VisualD.pdb    229    0.45.1-rc2    12/31/1969 7:00 PM    13FB0000-143C0000*    [8972] devenv.exe
>>>      VisualD.dll    C:\Program Files (x86)\VisualD\VisualD.dll    N/A Yes    Cannot find or open the PDB file.        271    0.45.1-rc2 12/31/1969 7:00 PM    18D40000-1904E000*    [8972] devenv.exe
>>>
>>>
>>> I was finally able to get it to work. Something is wonky. I think it's when I use a normal VS side by side with the experimental that the experimental can't find the symbols and somehow the registry changes I made got reset.
>>>
>>> So far it is working(I can hit BP's) but it's still basically the same scenario in that I have to completely shut down VS in order to reload visualD. Before I could automate because the normal visual studio instance could stay open... but it seems like it screws up the debugging symbols and such.
>>>
>>> I could try to use another, different exp instance(different registry) but I feel the same problem might occur.
>>>
>>> But I guess it's better than nothing.
>>>
>> 
>> Good to hear it (kind of) works now. VS2015 also resets the configuration rather often, so it's good to automate the patching.
>> 
>> I don't have troubles with exchanging the debug DLL while having the normal VS instance running. Maybe you have experimented with registry changes that now cause the debug DLL to be loaded there, too? Reinstalling Visual D should help in that case (though that will trigger rebuilding the user configuration).
>> 
>> I've tried to figure out why both DLLs are actually loaded (it has been bugging me before, too), but could not find the cause yet.
>
> I managed to load the Debug DLL into the "experimental" VS without any (explicit) registry patching:
>
> 1. delete HOME%\AppData\Local\Microsoft\VisualStudio\15.0_<id>Exp\privateregistry.bin to make sure to start from scratch
>
> 2. copy "c:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\Rainer Schuetze\VisualD" to "%HOME%\AppData\Local\Microsoft\VisualStudio\15.0_<id>Exp\Extensions\Rainer Schuetze\VisualD"
>
> 3. replace paths in Extensions\Rainer Schuetze\VisualD\0.45\visuald.pkgdef to point to the debug DLL
>
> 4. start "devenv /RootSuffix Exp"
>
> 5. enable "Visual D" in the "Extensions and Updates..." dialog
>
> 6. restart VS
>
> This even doesn't load the DLL twice for me.

This isn't working for me, even though it looks like it should. Those values in the pkgdef are exactly the ones I replaced in the privateregistry hive, but it seems that for some reason it is not being used ;/ (since my changes are not propagating to it)

This should work as this is really no different that what I was doing except it is more of the correct way.  I'm not sure what's going on but I'll try and figure it out. I probably need to use a clean instance of VS

It seems I have something weird going on. I have

15.0
15.0_4d0b469e
15.0_4d0b469eExp
15.0Exp which is empty except for a path containing VSTemplateStore.pkgdef and I don't believe this existed yesterday. I think I just created it with the util I used as I was trying to reset the exp instance(which I thought was the 3rd one).

I'm not sure where the others came from but I'm going to create a new rootsuffix and try everything on that. I guess the 15.0_4d0b469eExp is a _4d0b469eExp suffix and hence I'm not loading it ;/


Ok, I ran CreateExpInstance /create /VSInstance=15.0 /RootSuffix=VisualDExp and it created a 15.0VisualDExp dir.

So, looks like the 15.0Exp was what I just created and it wasn't being used when I ran /RootSuffix=Exp.. which I guess, because it didn't exist, just used the original data.

I ran devenv.exe /RootStuffix VisualDExp

and it created

15.0_4d0b469eVisualDExp

So, something is funky. I guess 15.0_4d0b469e is the version. It loads, though, Visual D, so it is picking up the extensions from the original.

This seems to be a problem with Visual Studio ;/

Yeah, so, tried with a fresh exp copied all the stuff you mentioned, checked the files and same thing. I'm using enterprise on windows 10 creators so there might be bugs. It's clearly not loading the package changes I made so either it's bugged or it's loading them from a different place.

I'll try again tomorrow and see if things change ;/

On 16.08.2017 16:48, Johnson wrote:
> On Wednesday, 16 August 2017 at 06:58:49 UTC, Rainer Schuetze wrote:
>>
>>
>> On 16.08.2017 08:32, Rainer Schuetze wrote:
>>>
>>>
>>> On 16.08.2017 04:49, Johnson wrote:
>>>>      VisualD.dll    C:\Program Files (x86)\VisualD\Debug\VisualD.dll N/A    Yes    Symbols loaded.
>>>>    C:\Program Files (x86)\VisualD\Debug\VisualD.pdb    229 0.45.1-rc2    12/31/1969 7:00 PM    13FB0000-143C0000* [8972] devenv.exe
>>>>      VisualD.dll    C:\Program Files (x86)\VisualD\VisualD.dll    N/A Yes    Cannot find or open the PDB file.        271    0.45.1-rc2 12/31/1969 7:00 PM 18D40000-1904E000*    [8972] devenv.exe
>>>>
>>>>
>>>> I was finally able to get it to work. Something is wonky. I think it's when I use a normal VS side by side with the experimental that the experimental can't find the symbols and somehow the registry changes I made got reset.
>>>>
>>>> So far it is working(I can hit BP's) but it's still basically the same scenario in that I have to completely shut down VS in order to reload visualD. Before I could automate because the normal visual studio instance could stay open... but it seems like it screws up the debugging symbols and such.
>>>>
>>>> I could try to use another, different exp instance(different registry) but I feel the same problem might occur.
>>>>
>>>> But I guess it's better than nothing.
>>>>
>>>
>>> Good to hear it (kind of) works now. VS2015 also resets the configuration rather often, so it's good to automate the patching.
>>>
>>> I don't have troubles with exchanging the debug DLL while having the normal VS instance running. Maybe you have experimented with registry changes that now cause the debug DLL to be loaded there, too? Reinstalling Visual D should help in that case (though that will trigger rebuilding the user configuration).
>>>
>>> I've tried to figure out why both DLLs are actually loaded (it has been bugging me before, too), but could not find the cause yet.
>>
>> I managed to load the Debug DLL into the "experimental" VS without any (explicit) registry patching:
>>
>> 1. delete HOME%\AppData\Local\Microsoft\VisualStudio\15.0_<id>Exp\privateregistry.bin to make sure to start from scratch
>>
>> 2. copy "c:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\Rainer Schuetze\VisualD" to "%HOME%\AppData\Local\Microsoft\VisualStudio\15.0_<id>Exp\Extensions\Rainer Schuetze\VisualD"
>>
>> 3. replace paths in Extensions\Rainer Schuetze\VisualD\0.45\visuald.pkgdef to point to the debug DLL
>>
>> 4. start "devenv /RootSuffix Exp"
>>
>> 5. enable "Visual D" in the "Extensions and Updates..." dialog
>>
>> 6. restart VS
>>
>> This even doesn't load the DLL twice for me.
> 
> This isn't working for me, even though it looks like it should. Those values in the pkgdef are exactly the ones I replaced in the privateregistry hive, but it seems that for some reason it is not being used ;/ (since my changes are not propagating to it)
> 
> This should work as this is really no different that what I was doing except it is more of the correct way.  I'm not sure what's going on but I'll try and figure it out. I probably need to use a clean instance of VS
> 
> It seems I have something weird going on. I have
> 
> 15.0
> 15.0_4d0b469e
> 15.0_4d0b469eExp
> 15.0Exp which is empty except for a path containing VSTemplateStore.pkgdef and I don't believe this existed yesterday. I think I just created it with the util I used as I was trying to reset the exp instance(which I thought was the 3rd one).
> 
> I'm not sure where the others came from but I'm going to create a new rootsuffix and try everything on that. I guess the 15.0_4d0b469eExp is a _4d0b469eExp suffix and hence I'm not loading it ;/
> 
> 
> Ok, I ran CreateExpInstance /create /VSInstance=15.0 /RootSuffix=VisualDExp and it created a 15.0VisualDExp dir.
> 
> So, looks like the 15.0Exp was what I just created and it wasn't being used when I ran /RootSuffix=Exp.. which I guess, because it didn't exist, just used the original data.
> 
> I ran devenv.exe /RootStuffix VisualDExp
> 
> and it created
> 
> 15.0_4d0b469eVisualDExp
> 
> So, something is funky. I guess 15.0_4d0b469e is the version. It loads, though, Visual D, so it is picking up the extensions from the original.
> 
> This seems to be a problem with Visual Studio ;/
> 
> Yeah, so, tried with a fresh exp copied all the stuff you mentioned, checked the files and same thing. I'm using enterprise on windows 10 creators so there might be bugs. It's clearly not loading the package changes I made so either it's bugged or it's loading them from a different place.
> 
> I'll try again tomorrow and see if things change ;/
> 

Starting with VS2017, it's supposed to be possible to have different copies of VS installed. I guess the additional hex value after 15.0 is represents each of these different installations.

I don't run "CreateExpInstance", I just start "devenv /RootSuffix Exp" (or another suffix) which creates 15.0_ade21380Exp for me. There is no 15.0 folder on my AppData directories.

I'm on Win10.0.14393 (pre-creator), VS 2017 community.

On Wednesday, 16 August 2017 at 17:54:39 UTC, Rainer Schuetze wrote:
>
>
> On 16.08.2017 16:48, Johnson wrote:
>> On Wednesday, 16 August 2017 at 06:58:49 UTC, Rainer Schuetze wrote:
>>>
>>>
>>> On 16.08.2017 08:32, Rainer Schuetze wrote:
>>>>
>>>>
>>>> On 16.08.2017 04:49, Johnson wrote:
>>>>>      VisualD.dll    C:\Program Files (x86)\VisualD\Debug\VisualD.dll N/A    Yes    Symbols loaded.
>>>>>    C:\Program Files (x86)\VisualD\Debug\VisualD.pdb    229 0.45.1-rc2    12/31/1969 7:00 PM    13FB0000-143C0000* [8972] devenv.exe
>>>>>      VisualD.dll    C:\Program Files (x86)\VisualD\VisualD.dll    N/A Yes    Cannot find or open the PDB file.        271    0.45.1-rc2 12/31/1969 7:00 PM 18D40000-1904E000*    [8972] devenv.exe
>>>>>
>>>>>
>>>>> I was finally able to get it to work. Something is wonky. I think it's when I use a normal VS side by side with the experimental that the experimental can't find the symbols and somehow the registry changes I made got reset.
>>>>>
>>>>> So far it is working(I can hit BP's) but it's still basically the same scenario in that I have to completely shut down VS in order to reload visualD. Before I could automate because the normal visual studio instance could stay open... but it seems like it screws up the debugging symbols and such.
>>>>>
>>>>> I could try to use another, different exp instance(different registry) but I feel the same problem might occur.
>>>>>
>>>>> But I guess it's better than nothing.
>>>>>
>>>>
>>>> Good to hear it (kind of) works now. VS2015 also resets the configuration rather often, so it's good to automate the patching.
>>>>
>>>> I don't have troubles with exchanging the debug DLL while having the normal VS instance running. Maybe you have experimented with registry changes that now cause the debug DLL to be loaded there, too? Reinstalling Visual D should help in that case (though that will trigger rebuilding the user configuration).
>>>>
>>>> I've tried to figure out why both DLLs are actually loaded (it has been bugging me before, too), but could not find the cause yet.
>>>
>>> I managed to load the Debug DLL into the "experimental" VS without any (explicit) registry patching:
>>>
>>> 1. delete HOME%\AppData\Local\Microsoft\VisualStudio\15.0_<id>Exp\privateregistry.bin to make sure to start from scratch
>>>
>>> 2. copy "c:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\Rainer Schuetze\VisualD" to "%HOME%\AppData\Local\Microsoft\VisualStudio\15.0_<id>Exp\Extensions\Rainer Schuetze\VisualD"
>>>
>>> 3. replace paths in Extensions\Rainer Schuetze\VisualD\0.45\visuald.pkgdef to point to the debug DLL
>>>
>>> 4. start "devenv /RootSuffix Exp"
>>>
>>> 5. enable "Visual D" in the "Extensions and Updates..." dialog
>>>
>>> 6. restart VS
>>>
>>> This even doesn't load the DLL twice for me.
>> 
>> This isn't working for me, even though it looks like it should. Those values in the pkgdef are exactly the ones I replaced in the privateregistry hive, but it seems that for some reason it is not being used ;/ (since my changes are not propagating to it)
>> 
>> This should work as this is really no different that what I was doing except it is more of the correct way.  I'm not sure what's going on but I'll try and figure it out. I probably need to use a clean instance of VS
>> 
>> It seems I have something weird going on. I have
>> 
>> 15.0
>> 15.0_4d0b469e
>> 15.0_4d0b469eExp
>> 15.0Exp which is empty except for a path containing VSTemplateStore.pkgdef and I don't believe this existed yesterday. I think I just created it with the util I used as I was trying to reset the exp instance(which I thought was the 3rd one).
>> 
>> I'm not sure where the others came from but I'm going to create a new rootsuffix and try everything on that. I guess the 15.0_4d0b469eExp is a _4d0b469eExp suffix and hence I'm not loading it ;/
>> 
>> 
>> Ok, I ran CreateExpInstance /create /VSInstance=15.0 /RootSuffix=VisualDExp and it created a 15.0VisualDExp dir.
>> 
>> So, looks like the 15.0Exp was what I just created and it wasn't being used when I ran /RootSuffix=Exp.. which I guess, because it didn't exist, just used the original data.
>> 
>> I ran devenv.exe /RootStuffix VisualDExp
>> 
>> and it created
>> 
>> 15.0_4d0b469eVisualDExp
>> 
>> So, something is funky. I guess 15.0_4d0b469e is the version. It loads, though, Visual D, so it is picking up the extensions from the original.
>> 
>> This seems to be a problem with Visual Studio ;/
>> 
>> Yeah, so, tried with a fresh exp copied all the stuff you mentioned, checked the files and same thing. I'm using enterprise on windows 10 creators so there might be bugs. It's clearly not loading the package changes I made so either it's bugged or it's loading them from a different place.
>> 
>> I'll try again tomorrow and see if things change ;/
>> 
>
> Starting with VS2017, it's supposed to be possible to have different copies of VS installed. I guess the additional hex value after 15.0 is represents each of these different installations.
>
> I don't run "CreateExpInstance", I just start "devenv /RootSuffix Exp" (or another suffix) which creates 15.0_ade21380Exp for me. There is no 15.0 folder on my AppData directories.
>

That's what I thought too, I have  15.0 folder that is empty. I had to install some pre-15 stuff to get some old stuff to compile and not sure if that was created from it or what. I only used CreateExpInstance today to try to start from scratch.  Again, I'm not sure what is going on but it seems like your method should work so I think it's on my end.  I think with a clean Exp install there should be no VisualD but there is, so somehow it is pulling in basically the non-exp setup instead of starting fresh.  I'll have look in to that to see if it's a known issue or if it's something else.

What's strange is that with your changes, privateregistry seems to use them... but it still loads the old(I think) visualD because when I try the debug the BP's are not hit and the module shows the original visualD directory.

It's most likely an issue with my setup. I might have to try to install on a virtual machine and see if the same behavior occurs or not. I'll double check things to make sure I didn't miss anything just in case.

On 16.08.2017 21:18, Johnson Jones wrote:
> What's strange is that with your changes, privateregistry seems to use them... but it still loads the old(I think) visualD because when I try the debug the BP's are not hit and the module shows the original visualD directory.

The Visual D installer adds the extension to the VS installation ("c:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\Rainer Schuetze\VisualD") so it is immediately available for all users and suffixes.

You can move it to "%HOME%\AppData\Local\Microsoft\VisualStudio\15.0_<id>\Extensions\Rainer Schuetze\VisualD" to load it only with the version without suffix. With both the system wide extension and the one in the "Exp" folder, the extension from the user folder took precedence for me, though.

If you run "devenv /RootSuffix Exp /Log" VS writes a log into "%APPDATA%\Roaming\Microsoft\VisualStudio\15.0_<id>Exp\ActivityLog.xml" that also lists detected extensions.

On Wednesday, 16 August 2017 at 19:35:19 UTC, Rainer Schuetze wrote:
>
>
> On 16.08.2017 21:18, Johnson Jones wrote:
>> What's strange is that with your changes, privateregistry seems to use them... but it still loads the old(I think) visualD because when I try the debug the BP's are not hit and the module shows the original visualD directory.
>
> The Visual D installer adds the extension to the VS installation ("c:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\Rainer Schuetze\VisualD") so it is immediately available for all users and suffixes.
>
> You can move it to "%HOME%\AppData\Local\Microsoft\VisualStudio\15.0_<id>\Extensions\Rainer Schuetze\VisualD" to load it only with the version without suffix. With both the system wide extension and the one in the "Exp" folder, the extension from the user folder took precedence for me, though.
>
> If you run "devenv /RootSuffix Exp /Log" VS writes a log into "%APPDATA%\Roaming\Microsoft\VisualStudio\15.0_<id>Exp\ActivityLog.xml" that also lists detected extensions.


I completely removed the `Extensions\Rainer Schuetze` directories in all visual studio folders that I know of:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\IDE\Extensions

C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469e
C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469eExp

Running visual studio still loads Visual D. It seems that it doesn't even use the visuald.pkgdef.

Obviously I have those entries in the registry. Which it seems it pulls from and either doesn't use the extensions folder at all on my system or is overridden by the registry entries? If that's the case, how can it be worked around? If not, what else might it be?

If visuald.pkgdef is suppose to be what visual studio uses to load visual D as an extension, does it import that in to the registry and then use the registry or does it always use the pkgdef file?(which doesn't seem to be the case, as, again, visual D is loading with visual studio without any of those pkgdef's)

What I'm afraid of is that deleting the registry keys will not do any good, they will just be re-imported by loading the pkgdef(or not, in which case Visual D won't be found at all) and then the main registry keys will be used for the Exp, like it is now.

Basically visual studio is not loading the pkgdef files either at all or only once, or every time but not allow them to overwrite the registry keys, or something else is going on that I can't seem to figure out.

On 17.08.2017 19:05, Johnson wrote:
> On Wednesday, 16 August 2017 at 19:35:19 UTC, Rainer Schuetze wrote:
>>
>>
>> On 16.08.2017 21:18, Johnson Jones wrote:
>>> What's strange is that with your changes, privateregistry seems to use them... but it still loads the old(I think) visualD because when I try the debug the BP's are not hit and the module shows the original visualD directory.
>>
>> The Visual D installer adds the extension to the VS installation ("c:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\Rainer Schuetze\VisualD") so it is immediately available for all users and suffixes.
>>
>> You can move it to "%HOME%\AppData\Local\Microsoft\VisualStudio\15.0_<id>\Extensions\Rainer Schuetze\VisualD" to load it only with the version without suffix. With both the system wide extension and the one in the "Exp" folder, the extension from the user folder took precedence for me, though.
>>
>> If you run "devenv /RootSuffix Exp /Log" VS writes a log into "%APPDATA%\Roaming\Microsoft\VisualStudio\15.0_<id>Exp\ActivityLog.xml" that also lists detected extensions.
> 
> 
> I completely removed the `Extensions\Rainer Schuetze` directories in all visual studio folders that I know of:
> 
> C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\IDE\Extensions
> 
> C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469e
> C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469eExp
> 
> Running visual studio still loads Visual D. It seems that it doesn't even use the visuald.pkgdef.
> 
> Obviously I have those entries in the registry. Which it seems it pulls from and either doesn't use the extensions folder at all on my system or is overridden by the registry entries? If that's the case, how can it be worked around? If not, what else might it be?
> 
> If visuald.pkgdef is suppose to be what visual studio uses to load visual D as an extension, does it import that in to the registry and then use the registry or does it always use the pkgdef file?(which doesn't seem to be the case, as, again, visual D is loading with visual studio without any of those pkgdef's)
> 
> What I'm afraid of is that deleting the registry keys will not do any good, they will just be re-imported by loading the pkgdef(or not, in which case Visual D won't be found at all) and then the main registry keys will be used for the Exp, like it is now.
> 
> Basically visual studio is not loading the pkgdef files either at all or only once, or every time but not allow them to overwrite the registry keys, or something else is going on that I can't seem to figure out.
> 
> 

I think you are right that VS imports the settings from the pkgdef only once, then uses the registry only.

Maybe try deleting the cache files in "%APPDATA%\Local\Microsoft\VisualStudio\15.0_<id>\Extensions".

On Thursday, 17 August 2017 at 17:45:35 UTC, Rainer Schuetze wrote:
>
>
> On 17.08.2017 19:05, Johnson wrote:
>> On Wednesday, 16 August 2017 at 19:35:19 UTC, Rainer Schuetze wrote:
>>>
>>>
>>> On 16.08.2017 21:18, Johnson Jones wrote:
>>>> What's strange is that with your changes, privateregistry seems to use them... but it still loads the old(I think) visualD because when I try the debug the BP's are not hit and the module shows the original visualD directory.
>>>
>>> The Visual D installer adds the extension to the VS installation ("c:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\Rainer Schuetze\VisualD") so it is immediately available for all users and suffixes.
>>>
>>> You can move it to "%HOME%\AppData\Local\Microsoft\VisualStudio\15.0_<id>\Extensions\Rainer Schuetze\VisualD" to load it only with the version without suffix. With both the system wide extension and the one in the "Exp" folder, the extension from the user folder took precedence for me, though.
>>>
>>> If you run "devenv /RootSuffix Exp /Log" VS writes a log into "%APPDATA%\Roaming\Microsoft\VisualStudio\15.0_<id>Exp\ActivityLog.xml" that also lists detected extensions.
>> 
>> 
>> I completely removed the `Extensions\Rainer Schuetze` directories in all visual studio folders that I know of:
>> 
>> C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\IDE\Extensions
>> 
>> C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469e
>> C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469eExp
>> 
>> Running visual studio still loads Visual D. It seems that it doesn't even use the visuald.pkgdef.
>> 
>> Obviously I have those entries in the registry. Which it seems it pulls from and either doesn't use the extensions folder at all on my system or is overridden by the registry entries? If that's the case, how can it be worked around? If not, what else might it be?
>> 
>> If visuald.pkgdef is suppose to be what visual studio uses to load visual D as an extension, does it import that in to the registry and then use the registry or does it always use the pkgdef file?(which doesn't seem to be the case, as, again, visual D is loading with visual studio without any of those pkgdef's)
>> 
>> What I'm afraid of is that deleting the registry keys will not do any good, they will just be re-imported by loading the pkgdef(or not, in which case Visual D won't be found at all) and then the main registry keys will be used for the Exp, like it is now.
>> 
>> Basically visual studio is not loading the pkgdef files either at all or only once, or every time but not allow them to overwrite the registry keys, or something else is going on that I can't seem to figure out.
>> 
>> 
>
> I think you are right that VS imports the settings from the pkgdef only once, then uses the registry only.
>
> Maybe try deleting the cache files in "%APPDATA%\Local\Microsoft\VisualStudio\15.0_<id>\Extensions".

Ok, It seems to be caching. I deleted everything in the main registry related to visualD and ran visual studio and it was still there!

Searched on line and came up with devenv updateconfiguration, reran VS, and VisualD was no longer there! Ran experimental and it's still there!

Used the same process to remove it from Exp.

So, this surely has to be caching, although I removed all the cache files I could fine from both versions.

As of this point there is nothing related to visualD in the registry nor the VS folders as far as I can tell and both versions are not finding visualD.

I will copy the modified pkgdef file to the exp dir and run it: Did nothing, Vi sual D didn't load! Copied the original pkgdef, no go.

Seems Visual studio is not using the pkgdef in

C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469eExp\Extensions\Rainer Schuetze\VisualD

I put the extensions folder in all the visual studio versions in that base dir and it didn't help(so it's not using any directory in C:\Users\Main\AppData\Local\Microsoft\VisualStudio).

Of course, at this point it means something is fubar'ed.

I went ahead and installed latest VD so I could get some work done. Seems like no problem.


So either visual studio is not doing what it's suppose to or it has more cache files laying around that I failed to delete, unless you see something different?

On Thursday, 17 August 2017 at 21:18:35 UTC, Johnson Jones wrote:
> On Thursday, 17 August 2017 at 17:45:35 UTC, Rainer Schuetze wrote:
>>
>>
>> On 17.08.2017 19:05, Johnson wrote:
>>> On Wednesday, 16 August 2017 at 19:35:19 UTC, Rainer Schuetze wrote:
>>>>
>>>>
>>>> On 16.08.2017 21:18, Johnson Jones wrote:
>>>>> What's strange is that with your changes, privateregistry seems to use them... but it still loads the old(I think) visualD because when I try the debug the BP's are not hit and the module shows the original visualD directory.
>>>>
>>>> The Visual D installer adds the extension to the VS installation ("c:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\Rainer Schuetze\VisualD") so it is immediately available for all users and suffixes.
>>>>
>>>> You can move it to "%HOME%\AppData\Local\Microsoft\VisualStudio\15.0_<id>\Extensions\Rainer Schuetze\VisualD" to load it only with the version without suffix. With both the system wide extension and the one in the "Exp" folder, the extension from the user folder took precedence for me, though.
>>>>
>>>> If you run "devenv /RootSuffix Exp /Log" VS writes a log into "%APPDATA%\Roaming\Microsoft\VisualStudio\15.0_<id>Exp\ActivityLog.xml" that also lists detected extensions.
>>> 
>>> 
>>> I completely removed the `Extensions\Rainer Schuetze` directories in all visual studio folders that I know of:
>>> 
>>> C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\IDE\Extensions
>>> 
>>> C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469e
>>> C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469eExp
>>> 
>>> Running visual studio still loads Visual D. It seems that it doesn't even use the visuald.pkgdef.
>>> 
>>> Obviously I have those entries in the registry. Which it seems it pulls from and either doesn't use the extensions folder at all on my system or is overridden by the registry entries? If that's the case, how can it be worked around? If not, what else might it be?
>>> 
>>> If visuald.pkgdef is suppose to be what visual studio uses to load visual D as an extension, does it import that in to the registry and then use the registry or does it always use the pkgdef file?(which doesn't seem to be the case, as, again, visual D is loading with visual studio without any of those pkgdef's)
>>> 
>>> What I'm afraid of is that deleting the registry keys will not do any good, they will just be re-imported by loading the pkgdef(or not, in which case Visual D won't be found at all) and then the main registry keys will be used for the Exp, like it is now.
>>> 
>>> Basically visual studio is not loading the pkgdef files either at all or only once, or every time but not allow them to overwrite the registry keys, or something else is going on that I can't seem to figure out.
>>> 
>>> 
>>
>> I think you are right that VS imports the settings from the pkgdef only once, then uses the registry only.
>>
>> Maybe try deleting the cache files in "%APPDATA%\Local\Microsoft\VisualStudio\15.0_<id>\Extensions".
>
> Ok, It seems to be caching. I deleted everything in the main registry related to visualD and ran visual studio and it was still there!
>
> Searched on line and came up with devenv updateconfiguration, reran VS, and VisualD was no longer there! Ran experimental and it's still there!
>
> Used the same process to remove it from Exp.
>
> So, this surely has to be caching, although I removed all the cache files I could fine from both versions.
>
> As of this point there is nothing related to visualD in the registry nor the VS folders as far as I can tell and both versions are not finding visualD.
>
> I will copy the modified pkgdef file to the exp dir and run it: Did nothing, Vi sual D didn't load! Copied the original pkgdef, no go.
>
> Seems Visual studio is not using the pkgdef in
>
> C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469eExp\Extensions\Rainer Schuetze\VisualD
>
> I put the extensions folder in all the visual studio versions in that base dir and it didn't help(so it's not using any directory in C:\Users\Main\AppData\Local\Microsoft\VisualStudio).
>
> Of course, at this point it means something is fubar'ed.
>
> I went ahead and installed latest VD so I could get some work done. Seems like no problem.
>
>
> So either visual studio is not doing what it's suppose to or it has more cache files laying around that I failed to delete, unless you see something different?

[Just me going step by step for reference:

I should mention that after installing the latest, Visual D also gets installed in the Exp version ;/ so it "magically" propagated to it.

The evidence seems to point to visual studio simply loading visual D from the system registry and completely bypassing everything else. It doesn't even look at the pkgdef's(or looked at them once and installed them, then uses the registry thereafter).

Does the visualD installer install registry keys? or just the pkgdef file and then somehow informs VS and then VS does it?

My guess is that Visual D installs the registry keys, possibly wrong/old way, VS uses the registry always to load them for all versions. One can use pkgdefs but it won't do any good if the values exist in the registry because they seem to take precedence.

One thing I didn't do because I just thought of it was, after I removed all the registry data and cleared all the caches, was to go to extensions in visual studio and see if I had to enable them... maybe VS scans the pkgdef files and just presents them and one must enable them? So, it might have actually worked when I thought nothing was showing up.  I figured it would show up automatically but I might be wrong about that?

Let me try again: after deleting registry, running /updateconfiguration. VisualD still exists!!(the opposite of what happened last time) I didn't delete the default pkgdef file though. Doing that fixed and reclearing all the cache file fixed the problem and now visual D isn't showing up!

So, it seems that it first uses the registry then the pkgdef file. It seems like it doesn't import that in to the main registry since I rechecked, if that's correct then that is good. What it would say is that the visual D installer shouldn't be adding registry keys if it is.

Now, the test: Copying the pkgdef stuff to the exp install...

That time it showed up automatically in the exp install. I did use the new version so maybe the rc1 had a problem with the pkgdef or I screwed it up when I edited the first time... Anyways

What I have now is Visual D in Exp and not in normal. The only pkgdef is in the Exp apps dir.
]

Ok, So I think we've gotten somewhere.

1. Install Visual D.
2. Remove all registry entries related to it(not sure it this breaks icons and other stuff(or if it all is duplicated in the pkgdef file).
3. Move the pkgdef file from the program files visual studio install dir to the appdata local one for each version of VS. Modify them to point them to the VisualD versions one wants to use.
4. Run devenv /updateconfiguration on all versions of VS to modify and clear their cache files.

This should get them to be using the pkgdef files without using the main registry and shouldn't interfer with each other, the way it's suppose to be!

I've tried it this way 3 times and it seems to work.

I think you might try to modify the installer to not install reg keys and try to install the extensions in the appdata dir instead of program files, at least for v2017. That seems to be the cleanest way to do it. If someone wants to use a different version they just have to modify the appropriate package to point to it(a find/replace op on one file rather than having to copy a bunch of stuff).

It seems that having the same data in 3 places is quite confusing and doesn't give the desired results. Of course, it all might have just been some weird issue with my comp. A completely fresh install on a new system would be the best test.