Hello,
I am including one dynamics library in my visual studio 2017 project and I am getting this error "byte is ambiguous". I tried std::byte, #undef _HAS_STD_BYTE before including headers but none of them worked for me and I've got many errors. Also I am not able to modify the header file and whenever I try to do so it says access to the path is denied.

Do you use using namespace std; somewhere in your code ? This could be the problem.

You could try

No I'm not using namespace std anywhere in my code. Why Byte would work?

Byte would work as Byte and byte are considered different types as the name is case sensitive.

In another header the type byte is defined as something different to unsigned char. Have you done a header search for byte to see where else it's defined?

I can't change the byte to Byte because the access to the path is denied.

<cstddef> has a C++17 enum class definition for byte/std::byte in it.

https://en.cppreference.com/w/cpp/types/byte

It seems a problem with the windows sdk version. Updating to a newer version is supposed to resolve the problem.

When using the #define WIN32_LEAN_AND_MEAN / preprocessor settings several (not needed) things a excluded. That may help also.

Yes, by adding this #define Win32_LEAN_AND_MEAN t, the error is solved. What exactly this definition will set in the code?

Changing basic types to new names just makes the code harder to read.
c++ has bool, and it has uint8_t (8 bits, one byte, standard name if someone didn't get that they can read documentation on it)

worse, by using char, there are magical things done to cout and in a couple of other places that treat char differently. If you hide it as a special integer type, then try to print it, you get gibberish instead of digits and it can be hard to see why esp if inexperienced.

I recommend not doing this at all, ever (again, talking simple built in type renames only). Opinions vary of course, you certainly CAN do it, and if required to do so, you can be stuck with it.

being a problem with windows.h figures. Many issues always seem to come back to that monstrosity! I always use WIN32_LEAN_AND_MEAN when using windows.h unless I get compile errors because.

#define WIN32_LEAN_AND_MEAN before including windows.h means that a bunch of stuff is bypassed in the include files used. There's pre-compiler tests for this in various places.

> Many issues always seem to come back to that monstrosity!

Almost all those issues would be faced by C++ programmers who refuse to use namespaces.
You get what you deserve, I suppose.

It has nothing to do with using namespace. It is a microsoft problem they introduced in a certain sdk version. They fixed it in newer version.

I had this problem once but unfortunately can't remember how I solved it...

It might not hurt to consider upgrading from VS 2017 to VS 2019 or VS 2022. VS 2022 if the 'puter is 64-bit Windows, VS 2019 if 32-bit.

VS 2017 is no longer being updated or supported, C++20 will never be added. VS 2019/2022 does have it.