[Question/Issue] Blur in .NetStandard class library

[sebandraos]

Hi,

I'm testing this as a .NetStandard compatible alternative to Fody but I'm coming up against some issues when referencing Blur 0.2.9-beta in a .NetStandard1.3 library. Is this indeed compatible with .NetStandard? If so, what is the appropriate setup? I am currently creating a file in my project and using it as an attribute, although I am planning on testing the Visitor pattern once this works. If this is not the right way, what is the correct setup for the targets etc.

Everything appears to be in place and I have copied the attribute setup as demonstrated in the readme but upon building I receive: Severity Code Description Project File Line Suppression State Error CS2012 Cannot open 'd:\Documents\visual studio 2017\Projects\TestNetStandard\TestNetStandard\obj\Debug\netstandard1.3\TestNetStandard.pdb' for writing -- 'The process cannot access the file 'd:\Documents\visual studio 2017\Projects\TestNetStandard\TestNetStandard\obj\Debug\netstandard1.3\TestNetStandard.pdb' because it is being used by another process.' TestNetStandard d:\Documents\visual studio 2017\Projects\TestNetStandard\TestNetStandard\CSC 1 Active Even if I change the Build Action of the attribute file (and remove references to it) to None, I get the same issue. Cheers

[71]

Hey there,

This is an issue encountered when VS keeps a file opened. Basically Blur extends the MSBuild process to edit files once they've been compiled by VS, but if it fails, sometimes MSBuild will keep these files opened, which means that Blur can't access them anymore. Right now, the only workaround I know of is to kill the MSBuild.exe process.

Lemme know if you want some more help.

[sebandraos]

Ok, great. That lets me reattempt the build but now I'm getting a null AssemblyResolver in the Mono.Cecil.MetaDataResolver ctor. but I will look into that and ensure that it's not coming from my end. Error -2147467261 Value cannot be null. Parameter name: assemblyResolver at Mono.Cecil.MetadataResolver..ctor(IAssemblyResolver assemblyResolver) at Mono.Cecil.ModuleDefinition.get_MetadataResolver() at Mono.Cecil.ModuleDefinition.Resolve(TypeReference type) at Mono.Cecil.MetadataResolver.GetType(ModuleDefinition module, TypeReference reference) at Mono.Cecil.MetadataResolver.Resolve(TypeReference type) at Mono.Cecil.ModuleDefinition.Resolve(TypeReference type) at Mono.Cecil.TypeReference.Resolve() at Blur.BlurExtensions.Is(TypeReference typeRef, Type type, Boolean acceptDerivedTypes) at Blur.BlurExtensions.Is[T](TypeReference typeRef, Boolean acceptDerivedTypes) at Blur.BlurExtensions.<>c__58'1.<GetAttributes>b__58_0(CustomAttribute x) at System.Linq.Enumerable.WhereEnumerableIterator'1.MoveNext() at System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable'1 source) at Blur.Processor.FixExternals() at Blur.Processor.Preprocess(Stream targetStream, Stream symbolStream) Thanks

[71]

Sorry, but I can't reproduce your issue. From what I'm seeing, the problem comes from Mono.Cecil, and it looks like it has to do with #306 precisely, but that's quite weird because Blur uses its own AssemblyResolver.

What version of Mono.Cecil is installed?

[sebandraos]

I'm just using the Cecil that's included in the Blur NuGet. I created a completely fresh repo to try and clear any issues with old Cecil versions etc but I am still getting the error. Interestingly I managed to build once but there seems to be something very fragile in the build/clean/build sequence. My repo is here is you want to try and repro github.com/sebandraos/NetStandardILWeavingTest or if you can see something patently wrong in the usage. Cheers

[71]

I'm encountering the same problem with your solution, and from what I'm seeing the problem somehow is my own. I'm trying to fix it right now, and will update you on the process.

[sebandraos]

Thank you Grégoire. I'm more than happy to help debug or resolve issues. Don't hesitate to throw things my way.

[sebandraos]

Hi, Have you made any progress on this? Is there somewhere I should start looking for the bug?

[71]

Hey there. I've been experimenting with a few different fixes, but so far nothing that really works.

With school and everything, I can hardly make the time to debug, but I'll see what I can do.

[71]

I am glad to say this issue has been fixed! I won't upload the fix before a long time because I have a lot of other bugs to fix and features to implement, but if you want to locally apply the fix, replace those lines by those:

assembly = AssemblyDefinition.ReadAssembly(targetStream, new ReaderParameters
{
    InMemory = true,
    ReadWrite = false,
    ReadingMode = ReadingMode.Immediate,
    AssemblyResolver = new AssemblyResolver()
});

By the way, sorry for taking so much time to fix such a simple issue! I've been extremely busy with school and other projects, and kind of gave up after failing to fix the bug.

[sebandraos]

That's great, thanks Grégoire. It might be a simple fix but that doesn't mean it's a simple bug. FYI I have made this change upon your latest commit in my fork and converted all the PCL projects to .NETStandard1.3. If it's of interest I can open a PR to merge those changes back into the master.

[71]

Yep, I'm watching it and noticed you made a few changes. Unfortunately I've added a few more things to avoid parsing assemblies multiple times. Speaking of which, didn't you have any problems when switching to csproj 2017? I've also done this, and my local solution is pretty much impossible to build now.

[sebandraos]

I was having issues but they have pretty much cleared up with my last few tweaks. I am only looking at the executable and library though, not the tests, CommonAttributes etc. as they seem to have other issues. I have now made the BLur.Libray auto-pack into a nuget and this works nicely. The only major issue I'm having is having to kill MSBuild after each build to be avoid a clash at the next. I managed to rebuild a version of Fody/PropertyChanged with Blur but whenever I tried to reference that package from another project things started getting very messy with the second project thinking BlurVisitor was defined in System.Diagnostics.Debug and therefore not being able to find it.

[71]

Good work! Yeah they've had some weird bugs since I switched to the 2017 dotnet toolchain. I too have a problem with MSBuild, and can't get my hands on fixing it. What's really weird is that Fody doesn't have the same problem, even though it uses a similar process.

I haven't had that problem yet, I'll look into it

[71]

Hey,

I'd just like to let you know that I just rewrote a big part of the processing part of Blur, which makes it much more stable. It also brings the ability to debug mixins, or weavers.

I'd like to get a few other things done, and I'll push the changes.