The Microsoft.SqlServer.Management.Smo.SqlDataType enum has a value for the timestamp type but not rowversion. I'm looking for an updated version of the assembly or an alternate enum type that supports it.
The existing enum has a value for Timestamp, but according to the rowversion documentation, timestamp is "deprecated and will be removed in a future version". I prefer to avoid using deprecated things :)
I can't find anything that indicates that SqlDataType.Timestamp is deprecated. The link you provide indicates that the "timestamp syntax" for rowversion is deprecated in T-SQL and that you should use rowversion instead, but it is up to the library maintainers to make sure that the correct syntax is implemented in their product. Should it come to pass that the timestamp syntax is actually removed in a future version, then I'm sure the library will be updated and the Timestamp enumeration value will still be backward compatible for code that uses it. Since they don't provide a RowVersion enumeration value, I would just use Timestamp.
Quick answer:
No, you don't need to use another type. Microsoft.SqlServer.Management.Smo.SqlDataType datatype is the right type to use. Despite the old-style name, Microsoft.SqlServer.Management.Smo.SqlDataType.Timestamp is the value returned by SMO for SQL Server columns of type rowversion.
What's being deprecated is the use of the type name "timestamp" in SQL Sever DDL statements. If your code is generating DDL statements containing the type name timestamp and sending them to SQL Server, you should change your code to use [rowversion][4] instead. But if you're just using SMO or any of the types which use the Microsoft.SqlServer.Management.Smo.SqlDataType type, you won't be affected by the name change on the server side.
Long Answer:
I'm going to combine a few quotes here to avoid re-inventing the wheel. First, some history from http://www.mssqltips.com/tip.asp?tip=1501:
This data type [ROWVERSION] was introduced in SQL Server 2000 to eventually replace the timestamp data type. In the ANSI-SQL definition, timestamp is defined as a date and time whereas Microsoft implemented it as a binary value that changes every time a row changes. Microsoft has warned that the use of timestamp will eventually be changed to adhere to the ANSI standard so its use for concurrency management should be avoided. Currently, both timestamp and rowversion are analogous to each other...
Note that Oracle and Postgres both use TIMESTAMP in the standards-compliant way, so it's a smart move by Microsoft to ditch the non-standard usage of timestamp to avoid making things harder for Oracle devs trying to work on SQL Server.
Anyway, the change from timestamp to rowversion is in name only. It doesn't impact the behavior of columns using that type. Per the MSDN docs for rowversion:
timestamp is the synonym for the rowversion data type and is subject to the behavior of data type synonyms. In DDL statements, use rowversion instead of timestamp wherever possible. For more information, see Data Type Synonyms (Transact-SQL).
If you dig into the docs for Data Type Synonyms:
All subsequent metadata functions performed on the original object and any derived objects will report the base data type, not the synonym. This behavior occurs with metadata operations, such as sp_help and other system stored procedures, the information schema views, or the various data access API metadata operations that report the data types of table or result set columns.
In other words, by the time SMO gets ahold of the metadata about the table, it only knows about rowversion. This means that tables with columns of type rowversion are being returned to SMO as Microsoft.SqlServer.Management.Smo.SqlDataType.Timestamp
The SMO API never caught up with the new naming used by SQL Server. But because the underlying behavior of the type didn't change, only the name, your SMO client code does not need to change.
If your code is displaying SQL Server data types, you can be a good citizen and change that code to display "rowversion" instead of "timestamp". But otherwise your code doesn't need to change at all. In fact, most SMO clients (including Visual Studio's table design tool!) never even bothered to change their UI to reflect the new naming. Because those UIs connect to the enum under the covers, the SMO API clients will continue working regardless of what SQL Server calls the type in DDL.
It's possible that a future rev of the SMO API might also add a synonymous value to the enum (e.g. Microsoft.SqlServer.Management.Smo.SqlDataType.RowVersion) with the same underlying numeric value, but given that existing clients aren't broken this is probably a low priority for them.