我假设您的应用程序不是有状态的，这意味着它将被启动和停止多次。
我会考虑使用一个应用程序设置，在一个标准的.NET项目是一个选项，可供您读/写。该值可以是强类型的，并将存储在应用程序配置文件中。
示例：http://msdn.microsoft.com/en-us/library/aa730869%28VS.80%29.aspx

如果你不想使用数据库，你可以把最后使用的ID存储在你的application configuration settings中。

在属性文件中保留上次使用的值，您可能已经在使用该属性文件来保留您可能执行的许多其他初始设置。

如何保持一个文件，只是最近使用的号码它

存储在数据库里没什么不好。它可以使用一个只有一条记录的表，带有一个（整数）字段。或者记录的其他字段可以用于应用的其他状态。（如果将它与期望唯一键的东西一起使用，它可以有一个代理主键，它将只有一个固定值，例如。总是1。）递增它将通过读取然后写入该值并返回新值的事务来完成。（这样，如果并发调用，它将返回唯一的值。）当（且仅当）您已经有一个数据库时，这可能很方便。
对于InterBase或FireBird，您可以使用Generator（支持线程安全递增的标量值）。
或者，您可以将其存储在文件中。（它可以在同一个目录中，命名为使它不会与其他输出文件冲突。）您将打开该文件进行写入，读取它，用新值覆盖，然后关闭它。如果两个进程或线程试图同时更新它，其中一个将因锁定错误而失败，并且必须重试（从而获得下一个数字）。
这同样可以用存储值的任何其他方式来完成，例如您的应用程序配置设置文件，如其他人所建议的，或Windows注册表（主要原因是，如果你想它之间的共享程序可能安装在不同的地方在机器上，但在输出文件目录中的文件也实现了这一点）。但如果可以并发调用它，则必须确保所选择的任何机制都能处理此问题。
如果您不想单独存储计数器，并且旧文件永远不会被删除，则可以使用优化的方法来测试最后一个是什么，例如测试数字为1的文件的存在（带填充），然后将此值加倍并再次测试，直到您找到一个不存在的文件，然后测试最后一个找到的文件和最低不存在的文件之间的值。然后重复选择剩余可能范围中间的一个，直到剩余范围是一个值。它可能不会更快，这取决于测试文件是否存在所需的时间。如果不添加锁定机制（例如创建一个虚拟文件并保持其打开，同时执行此操作，然后删除它（并等待此文件是否存在并锁定写入）），则这对于并发访问不起作用。
当然，如果创建文件的进程在每次文件创建之间继续运行，并且是创建它们的唯一进程，则可以将计数器保存在内存中，并且只需在每次进程启动时重新建立值。（如果多个线程可以创建文件，则必须同步对计数器的访问。）