One thing I can suggest is that you copy the .NET 1 DLLs form the virtual machine to the copied project in your workstation and re-target the references to the system DLLs. The way Visual studio resolves, for instance the reference to System.Windows.Forms, is by seeing what assembly you want to reference by name, and if it's a framework one, target the one in the currently targeted platform. What this means is, JustDecompile decompiled your assembly targeting System.Windows.Forms v1.0.5000.0, but your VS targets System.Windows.Forms v188.8.131.52. By copying the assembly somewhere on your machine (for instance in a "References" subfolder of the created project) you can tell VS "Hey, target this particular file". Sadly, this will not work for mscorlib, as it is inferred by default by VS.
JustDecompile can do all this for you, if you have the files, but do NOT have the framework installed. As an example, if you simply copy-paste the .NET 1.0/1.1 framework folder anywhere on your workstation (for instance in the Desktop) and place the dll you try to decompile inside, all the "Use this file" referencing will be done automatically.
About the project format: in this case JustDecompile just organizes the project in the VS2010 format. VS infers it should target .NET 4.0, since this is the default value. If the projects were for .NET 2.0/3.5, JD would've indicated this in the .csproj, but since VS doesn't support older versions, we prefer not to make the project unopenable.
The number 38,000 seems really big for an average DLL. If retargeting the references doesn't lower this number significantly, please don't hesitate to write us back.