briefly connect the reset pin of the micro to ground - when you disconnect reset from ground, is it briefly detected by the operating system?
If yes, the last sketch uploaded was sufficiently broken that it hosed the USB functionality. Unlike, for example, an Uno or Nano, the micro has native USB, meaning the USB is directly connected to the microcontroller - as opposed to an uno or nano, where it connects to a USB-serial adapter, which connects to the non-USB microcontroller via serial. While this lets you do cool things like making the arduino act as a USB input device (like a keyboard or mouse), it also means that if your sketch crashes the microcontroller, it can’t service the USB requests, and thus the computer can’t detect it or tell it to reset into the bootloader to accept a new sketch.
An example of the sort of thing that can break a micro in this way would be a sketch that writes off the end of an array (this generally crashes or resets the microcontroller), or that reconfigures the USB functionality improperly.
If this is the case, you will need careful timing. Hold your mouse over the tools menu, reset (as described above) the micro and very quickly select the port from tools → port (you have to click to open the tools menu while it is detecting).
Then open blink or bare minimum - some safe sketch that you know won’t crash it. Keep the micro in reset (reset connected to ground), click upload, and disconnect reset from ground the instant the IDE console shows the size of the compiled sketch (may take a few tries to get the timing right). Thus, it will come out of reset into the bootloader right when the IDE tries to communicate with it, and it will be able to accept the sketch. Once the clean sketch is uploaded, the board will be detected during normal operation and will work again.