intercom / intercom-dotnet

Intercom API client library for .NET
https://developers.intercom.io/reference
Apache License 2.0
63 stars 53 forks source link

The output type of the library is wrong causing namespacing problems #115

Closed kmossco closed 6 years ago

kmossco commented 6 years ago

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:

image

Kudos to @leviathan898 for spotting this. Will try to get a new release out asap!

a-patel commented 6 years ago

Any update?

kmossco commented 6 years ago

Should have this done either today or tomorrow. πŸ‘

a-patel commented 6 years ago

@kmossco Thanks

alx-andru commented 6 years ago

looking forward to a fixed version 😁

kmossco commented 6 years ago

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?

a-patel commented 6 years ago

@kmossco I am still unable to Intercom classes. intercom-error

kmossco commented 6 years ago

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?

kmossco commented 6 years ago

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.

a-patel commented 6 years ago

I am using ASP.NET Core (2.0). I have also tried in .NetCore Console application but still same issue.

a-patel commented 6 years ago

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).

a-patel commented 6 years ago

I need it urgently. Thanks in advance.

alx-andru commented 6 years ago

Can confirm 2.0.2-beta shows same behaviour

DotJoshJohnson commented 6 years ago

@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.

alx-andru commented 6 years ago

@DotJoshJohnson Just tried a blank new project via

  1. dotnet new webapi
  2. dotnet add package Intercom.Dotnet.Client --version 2.0.2-beta
  3. dotnet restore
  4. dotnet build
  5. 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]

DotJoshJohnson commented 6 years ago

@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!

alx-andru commented 6 years ago

@DotJoshJohnson ahh, so I guess you guys are just pushing out a new beta soon.

kmossco commented 6 years ago

@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! πŸ‘‚

DotJoshJohnson commented 6 years ago

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.

kmossco commented 6 years ago

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?

neooleg commented 6 years ago

@kmossco can you publish a NuGet package?

It will allow us test and verify it in real life!

Thanks in advance!

kmossco commented 6 years ago

@neooleg I will try to get a release out this week. πŸ‘Will keep this open until that's out.

neooleg commented 6 years ago

@kmossco to kindly follow-up - is there is any update for release?

kmossco commented 6 years ago

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.

kmossco commented 6 years ago

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. πŸ‘