Are Bitcoin ASICs Optimized for Fixed Length Messages? Bitcoin block headers are 80 bytes. 

int32_t nVersion;       // 4 bytes
uint256 hashPrevBlock;  // 32 bytes
uint256 hashMerkleRoot; // 32 bytes
uint32_t nTime;         // 4 bytes
uint32_t nBits;         // 4 bytes
uint32_t nNonce;        // 4 bytes
                        // total: 80 bytes


A SHA256 ASIC is specifically designed to (double) hash theses fields over and over until the resulting value is below the difficulty level, which is encoded by nBits. 

Since it is a double hash, the ASIC has to be able to hash initial messages of length 80 and 32. After the padding required for SHA256, the byte strings that will be hashed have lengths 128 and 64, respectively. So, bitcoin ASICs obviously have to able to hash messages of length 128 and 64.

But say I have a file on my computer that is considerably longer (10,000x longer). Could I hash it with a SHA256 bitcoin ASIC?

Does it vary from SHA256-ASIC to SHA256-ASIC depending on how they are made?
What do you mean by "really long"? If it's bigger than (2^64-1)/8 bytes (~2,097,152 terabytes) then it's not going to work anyway because this is the theoretical limit of SHA256 and on top of that it would take a huge amount of time to complete, but then again I am not aware of many computers that can hold such great amounts of data.  

For significantly smaller inputs it all comes down on the way the ASIC's SHA256 engine is implemented, what is the size of message (input) block in bits, how much memory is available per core in your SHA256 ASIC, etc. As per market standard, these cores are usually equipped with 128 kilobytes of memory. Of course nothing stops you from deploying external units of DRAM memory chips across memory-bus enabled ASICs but this will fire back in processing speed anyway.