Closed kmossco closed 6 years ago
Any update?
Should have this done either today or tomorrow. π
@kmossco Thanks
looking forward to a fixed version π
I have now pushed a new version to Nuget that should fix this. Can you try 2.0.2-beta and see if that works?
@kmossco I am still unable to Intercom classes.
Thank you for the report @a-patel. Just to be sure, can you tell me what type of project this is? Is it NetCore, NetStandard? And is it a Console App or a Class Library?
I did a few tests and it seems that if I pull from Github and build the .dll locally I can add it correctly to either to a NetCore console app, or a NetStandard/NetCore library.
However if I install from NuGet, I keep having the namespacing problem. Investigating if there's anything in the build in NuGet that could be causing this.
I am using ASP.NET Core (2.0). I have also tried in .NetCore Console application but still same issue.
I am able to load all core domain Intercom classes, when I am using version 1.0.31. But I am not getting the valid response. Response is always null and not getting any exception. (I also chat with your live support but no luck)
FYI: For that I am using ASP.NET Core (2.0).
I need it urgently. Thanks in advance.
Can confirm 2.0.2-beta
shows same behaviour
@kmossco - I don't know if you guys run local builds before deploying or use a build server, but if you build locally, you'll want to ensure you do a Rebuild so the cached build objects are purged. I've had issues in the past where changes to the *.csproj
alone were not enough to trigger a full rebuild, so the previously-built assembly was used.
@DotJoshJohnson Just tried a blank new project via
dotnet new webapi
dotnet add package Intercom.Dotnet.Client --version 2.0.2-beta
dotnet restore
dotnet build
dotnet run
and tried to use Intercom.Core
in the generated ValuesController.cs. Result is the same
The type or namespace name 'Intercom' could not be found (are you missing a using directive or an assembly reference?) [intercom-test]
@alx-andru - Right. My thought is that the build published to NuGet contains an "old" assembly and thus does not contain the new target platform. I just confirmed this theory by creating a new *.nupkg
using what is currently in master
and I was able to load the package and reference the Intercom namespaces just fine.
@kmossco - If I can help in any way, let me know!
@DotJoshJohnson ahh, so I guess you guys are just pushing out a new beta soon.
@DotJoshJohnson we are currently building through MyGet and I think you are right here, there is something different there from how we build locally and that MyGet build that is causing this problem. Because building locally it works fine by me and a few others.
I am investigating this further to see what could be causing it, but if anyone has any experience with what this could be it I'm open to ideas! π
I deconstructed the *.nupkg
and found it contains the entire source tree, not just the usual lib
folder with the release assets. I'm not familiar with MyGet, but I'll continue digging around to see if I can find any other info. But this is almost certainly what is causing the problem for consumers of the package.
This should be fixed now thanks to @thewheat! Thank you so much for all your help @DotJoshJohnson , @alx-andru and @a-patel. π€Can you please try pulling from master and seeing if this is fixed for you as intended?
@kmossco can you publish a NuGet package?
It will allow us test and verify it in real life!
Thanks in advance!
@neooleg I will try to get a release out this week. πWill keep this open until that's out.
@kmossco to kindly follow-up - is there is any update for release?
So sorry for the delay in getting back to you here. We've been trying to push a new version to NuGet but ended up having a few problems getting the versions right so had to remove a few orphan packages due to that broken build process.
I have now reviewed and hopefully fixed the build process π€and that should let us have that package out very soon.
We had a few bumps getting our workflow up to speed to be able to push new versions to NuGet, but this is now fixed. I have now released a new version: 2.0.3-beta. This should fix the namespacing problem. π
We seem to have accidentally set the output type of the library as a console app, so if we use it in a class application it fails like this:
Kudos to @leviathan898 for spotting this. Will try to get a new release out asap!