Re# doesn't play nicely with dynamic definition of namespace about dllexport HOT 30 CLOSED

hmm, object model should be fully updated automatically... need to think

this only with Re# ?

from dllexport.

I'm brand new to this repo, but it looks like vb.net is having the same trouble? Using Visual Studio 2010 + .Net 4.0 + Nuget package version 1.3.0.

from dllexport.

:) strange, it's not reproduced for me at all.

Did I understand correctly that problem only with tips from IDE above and export works well ?

What after restarting IDE ? or reloading of projects/solution when it installed ?

from dllexport.

As far as I can tell, it's not causing any problems. Just instead of using the custom namespace, it's using that really long string.

from dllexport.

+jonsq

I see, thanks !

However it not reproduced for me :( need to think

my gif illustration here: #6 (comment)

All details about this here: Dynamic definitions of namespaces

What after restarting IDE ?

from dllexport.

What after restarting IDE ? or reloading of projects/solution when it installed ?

Already tried. Nothing have changed.
A program compiles fine though.

One more thing, once that namespace (with DllExportAttribute class) is imported, it magically makes a program uncompilable:

CS0246: The type or namespace name 'D3F00FF1770DED978EC774BA389F2DC901F4' could not be found (are you missing a using directive or an assembly reference?)

Edit:

this only with Re# ?

Apparently it is not, now I don't know what to change the title to.

Edit 2:
Why over complicate stuff.. Seriously, make it simple and consistent with .NET Framework, just move DllExportAttribute class in the same namespace where DllImport class resides, which is: System.Runtime.InteropServices. That way it is static namespace, it may solve the other issue as well, save yourself time.
In my opinion, "dynamic definition of namespace" shouldn't have reached NuGet (as "stable"). Well, since it already did, I suggest to revert that change, and do what I have just said above (make it static namespace) -- before it hits more downloads!

from dllexport.

Installation log (I have used ExportedLibrary for dynamic namespace):

Attempting to gather dependency information for package 'DllExport.1.3.0' with respect to project 'ExportedLibrary', targeting '.NETFramework,Version=v4.6.1'
Attempting to resolve dependencies for package 'DllExport.1.3.0' with DependencyBehavior 'Lowest'
Resolving actions to install package 'DllExport.1.3.0'
Resolved actions to install package 'DllExport.1.3.0'
Adding package 'DllExport.1.3.0' to folder '...\packages'
Added package 'DllExport.1.3.0' to folder '...\packages'
Added package 'DllExport.1.3.0' to 'packages.config'
Executing script file '...\packages\DllExport.1.3.0\tools\install.ps1'...


Name                  : DllExportNamespace
UnevaluatedValue      : ExportedLibrary
IsEnvironmentProperty : False
IsGlobalProperty      : False
IsReservedProperty    : False
Xml                   : Microsoft.Build.Construction.ProjectPropertyElement
Predecessor           : 
IsImported            : False
EvaluatedValue        : ExportedLibrary
Project               : Microsoft.Build.Evaluation.Project

Name                  : DllExportNamespace
UnevaluatedValue      : ExportedLibrary
IsEnvironmentProperty : False
IsGlobalProperty      : False
IsReservedProperty    : False
Xml                   : Microsoft.Build.Construction.ProjectPropertyElement
Predecessor           : 
IsImported            : False
EvaluatedValue        : ExportedLibrary
Project               : Microsoft.Build.Evaluation.Project

defNS: (...\packages\DllExport.1.3.0\lib\net20\DllExport.dll); (ExportedLibrary)
1489
4
1457
The DllExport Library has been modified !
namespace: ExportedLibrary
Details here: https://github.com/3F/DllExport/issues/2


Successfully installed 'DllExport 1.3.0' to ExportedLibrary
========== Finished ==========

I have found a way-around this, that is, create own DllExportAttribute class and use it (seems like #2 has failed a lot)..

from dllexport.

seems like #2 has failed a lot

I see only report from #6 and also not for all. But, I already pushed changes for this - https://ci.appveyor.com/project/3Fs/dllexport/history, so probably it already fixed (I don't see any replies from this guys) -

when I will get a time for this project, I will start new release with this changes (+some changes from current issues)

For this issue:

! btw, please check this problem with latest changes from master - bcfa5cc

need to details, I will look it later because it also should be ok. The DllExport Library has been modified ! Therefore, the 'D3F00FF1770DED978EC774BA389F2DC901F4 cannot be at all (see 3 item)

The main problem how to reproduce it for me :(

from dllexport.

btw, please check this problem with latest changes from master

Ok. I have just tested this with nightly build NuGet package (link). Restarted VS2015, and created an empty console application, and then installed NuGet package from local folder. Still, nothing have changed.
Here is installation log of this time (now I have used "System.Runtime.InteropServices" as dynamic namespace):

Attempting to gather dependency information for package 'DllExport.1.3.0' with respect to project 'ExportedLibrary', targeting '.NETFramework,Version=v4.6.1'
Attempting to resolve dependencies for package 'DllExport.1.3.0' with DependencyBehavior 'Lowest'
Resolving actions to install package 'DllExport.1.3.0'
Resolved actions to install package 'DllExport.1.3.0'
Adding package 'DllExport.1.3.0' to folder '...\packages'
Added package 'DllExport.1.3.0' to folder '...\packages'
Added package 'DllExport.1.3.0' to 'packages.config'
Executing script file '...\packages\DllExport.1.3.0\tools\install.ps1'...


Name                  : DllExportNamespace
UnevaluatedValue      : System.Runtime.InteropServices
IsEnvironmentProperty : False
IsGlobalProperty      : False
IsReservedProperty    : False
Xml                   : Microsoft.Build.Construction.ProjectPropertyElement
Predecessor           : 
IsImported            : False
EvaluatedValue        : System.Runtime.InteropServices
Project               : Microsoft.Build.Evaluation.Project

Name                  : DllExportNamespace
UnevaluatedValue      : System.Runtime.InteropServices
IsEnvironmentProperty : False
IsGlobalProperty      : False
IsReservedProperty    : False
Xml                   : Microsoft.Build.Construction.ProjectPropertyElement
Predecessor           : 
IsImported            : False
EvaluatedValue        : System.Runtime.InteropServices
Project               : Microsoft.Build.Evaluation.Project

set new namespace: (System.Runtime.InteropServices) - (...\packages\DllExport.1.3.0\lib\net20\DllE
xport.dll)
The DllExport Library has been modified !
namespace: System.Runtime.InteropServices
Details here: https://github.com/3F/DllExport/issues/2


Successfully installed 'DllExport 1.3.0' to ExportedLibrary
========== Finished ==========

Edit:
Moreover, I have just searched in Object Browser (with all components selected), and it couldn't find anything by searching "DllExportAttribute". Now, this is even more strange...

from dllexport.

@OmegaExtern

just noticed your new edit 2 :)

just move DllExportAttribute class in the same namespace where DllImport

it already was in v1.1 ! but after short discussion with Robert I decided to provide more compatible solution.

He said simply:

What you should never, ever do is putting stuff in a general namespace like System.Runtime.InteropServices.

I wrote:

I do not think so :) ...

... and main part of my thoughts here as an my short explanation to Robert that DllExport it's special case.

with important note about problems that can be - DllExport & InteropServices it more likely a theoretical-potential problems, but yes, conflicts are possible. - That I said.

My final decision you already know, and mainly I like it more, because I want to use System.Runtime.InteropServices in my X projects, but not everyone likes it and wants to something other (that soundly)

bugs ?

bugs everywhere

just to fix it :)

from dllexport.

I still can not reproduce your problems. I also tried in VM with different locale but no result. All works fine, damn :)

@OmegaExtern @jonsq

ok ! I already started new GUI configurator, that also affects on this feature.

So, please test it from develop branch - ba0da45

from dllexport.

please report about result (latest changes: 00bede7 see binaries from CI)

from dllexport.

v1.4:

    * NEW: GUI Configurator with updated ddNS features.
    * OTHER: other possible changes and fixes.

reopen if needed

from dllexport.

I'm back.
So, I installed fresh v1.4 package. Screenshot of settings:

Package Manager output:

Attempting to gather dependency information for package 'DllExport.1.4.0' with respect to project 'ExportedLibrary', targeting '.NETFramework,Version=v4.6.1'
Attempting to resolve dependencies for package 'DllExport.1.4.0' with DependencyBehavior 'Lowest'
Resolving actions to install package 'DllExport.1.4.0'
Resolved actions to install package 'DllExport.1.4.0'
  GET https://api.nuget.org/packages/dllexport.1.4.0.nupkg
  OK https://api.nuget.org/packages/dllexport.1.4.0.nupkg 83ms
Installing DllExport 1.4.0.
Adding package 'DllExport.1.4.0' to folder '...\packages'
Added package 'DllExport.1.4.0' to folder '...\packages'
Added package 'DllExport.1.4.0' to 'packages.config'
Executing script file '...\packages\DllExport.1.4.0\tools\init.ps1'...
Executing script file '...\packages\DllExport.1.4.0\tools\install.ps1'...
set new namespace: (ExportedLibrary) - (...\packages\DllExport.1.4.0\lib\net20\DllExport.dll)
binmod: lpos(1425); ident(32)
binmod: buffer(500); fullseq(534)

The DllExport Library has been modified !

namespace: 'ExportedLibrary' :: ...\packages\DllExport.1.4.0\lib\net20\DllExport.dll
Details here: https://github.com/3F/DllExport/issues/2
The Export configured for platform: x86
The Base for ordinals: 1
Successfully installed 'DllExport 1.4.0' to ExportedLibrary
========== Finished ==========

And apparently this issue is still a thing. Reopen it.

from dllexport.

:) holy hedgehogs

please attach all files from your packages\DllExport.1.4.0\lib\net20\:

• DllExport.dll.ddNSi
• DllExport.dll

and also check paths to dll in References in your project file (.csproj etc)

from dllexport.

Compressed in Zip file: net20.zip

from dllexport.

in your project file (.csproj etc)

Okay, maybe this would help:
In project file, "DllExportNamespace" seems to be invalid child element, however Re# doesn't say the same for "DllExportOrdinalsBase" (the latter seems to be valid).

See source for project file, here.

from dllexport.

still all works fine (14.0.25421.03 Update 3)

but I found possible problem in 0x007A7-0x007A8 however strange that VS works correctly for me -_-

I changed 2 bytes manually for your library, can you check:

• Close VS IDE
• replace DllExport.dll from me - mod_DllExport.zip
• Open this project again

why you think that's invalid ?

...
<DllExportNamespace>ExportedLibrary</DllExportNamespace>
...

from dllexport.

by the way, again, you should not see sequence D3F00FF1770DED978E... at all, it's marker only, that can be updated for zero-based sequence that will be considered as a null-terminated string.

Therefore GAC ? I remembered this JamesNK/Newtonsoft.Json#647 or some other cache.
Can you also check this or something else ? if mod_DllExport.zip does not help

from dllexport.

14.0.25421.03 Update 3

Mine is 14.0.25425.01 Update 3. Your VS is older.
Re# is 2016.2.2 Build 106.0.20160913.91321.
For those who don't know, there is an option to disable the popup though, in options search for Show the Import namespace action using popup:

I changed 2 bytes manually

Ok, 0x30 0x30 to 0x00 0x00 at location 0x7A7.

can you check

Ok. Finally:

So... Why the two bytes must be manually changed?

from dllexport.

why you think that's invalid ?

It is not me, it is Re# that reported it, see (even after above manual DllExport patch):

But, this doesn't really matter, right?

from dllexport.

Mine is 14.0.25425.01 Update 3. Your VS is older.

how about very older VS2010 from +jonsq ? just a note

Ok. Finally:

o_O I didn't understand - this works or not ?

Why the two bytes must be manually changed?

0x30 0x30 is not correct (for our case) for zero-based sequence that will be considered as a null-terminated string. see above

just a typo, later I will fix it ! Yes, 0x007A7-0x007A8 is also need to fix even if it not a reason of this ! yesterday I changed it manually because it was faster to check on your prepared project.

It is not me, it is Re# that reported it

it's warning of schema only - see xmlns

But, this doesn't really matter, right?

yes, for this issue it should not be related at all. And mainly this as part of full identifier to work with data via Cecil

from dllexport.

I didn't understand - this works or not ?

Yes, your manual patch worked (see screenshot?).

from dllexport.

Yes, your manual patch worked

Good !

How about Object Browser ?

and note for 0x30 0x30 is not correct for zero-based ... I mean like for our case, well I think you understood me :)

from dllexport.

How about Object Browser ?

I have checked it already, and I could not find "ExportedLibrary" project nor anything about "DllExport". I have selected to search all components and still nothing... Possible VS bug?

from dllexport.

@OmegaExtern

• ca2d68b solves problem with 0x30 0x30, as I said just a typo: sizeof(UInt16) -> sizeof(UInt16) * 2
• 38c5388 I also added Cecil variant for ddNS features. Now you can try both variant with GUI Configurator. Or set msbuild property DllExportDDNSCecil as true

And I tested both variant for VS2010 v10.0.30319.1 (without SP1) in VM

in general, try this 54263f9 ...

from dllexport.

I am waiting for nightly build, or is this the build d17e335?
If that's build d17e335, then you didn't solve it:

If it is not build d17e335, please upload it; I can't be bothered to compile this from source code..

from dllexport.

amazing o_o
I was waiting for the results of latest changes i.e. the d17e335 should include all fixes for this.

Did you check both type of changes - Cecil and Direct-Mod ? this is for both options ?

from dllexport.

Ok, this is weird, but there's some sense. It happens with both, Cecil and Direct-Mod.
So, I have reloaded a project and it fixed itself. Well, well, well, unload project (before NuGet package is installed, or before a project file is modified), then load project (after NuGet package is installed, or after a project file is modified).
I sure that will fix it, like 100% sure.

from dllexport.

@OmegaExtern

just for checking: the any install/remove operation for this package will load our assemblies into main domain of VS !

Before, I used this to avoid problem with loading of .net assemblies:

powershell -Command "Import-Module (Join-Path $ToolsPath Configurator.dll); Set-Configuration -Dll $asmpath"

it was simply, but now I need to provide via -Command a complex objects (EnvDTE.Project & Microsoft.Build.Evaluation.ProjectCollection), and seems it's not possible (I'm not sure, I do not use powershell so often) like -ProjectDTE $project -ProjectsMBE $gpc etc.

of course I can prepare all this inside like in my other plugin (that contains complex support of EnvDTE & MS Build.Evaluation) , but I don't want hard impl. for DllExport

Therefore, the other easy way to use through temp assemblies:

$dllConf = Get-TempPathToConfiguratorIfNotLoaded 'net.r_eg.DllExport.Configurator.dll' "$toolsPath"
if($dllConf) {
    Import-Module $dllConf; 
}

Set-Configuration -MetaLib "$metaLib" -InstallPath "$installPath" -ToolsPath "$toolsPath" -ProjectDTE $project -ProjectsMBE $gpc;

ah yes, I also thought about this but for common solution I have no time yet. later

So ! if you already have installed package, to full upgrade on new version, please restart IDE if [remove] button is clicked before.

from dllexport.