I'm trying to use the Protobuf C# Port that was developed by Jon Skeet's on a Unity project, but I keep getting errors when I try to build and run a stand alone. I have copied over all the .dll files into the assets and things run smoothly while I'm running unity from developer environment, but as soon as I compile and build I get an error about a "filename unkown".
error image
I haven't managed to find a solution because it seems that most people run into similar issues using Marc Gravell's version of Protobuf. I'd like to stick to the version that I'm using now since I will be working with several languages for this project.
Any help is greatly appreciated.
-- Solution --
It turns out that I had to go into Edit > Project Settings > Player and change the NET version from 2.0 Subset into 2.0
I often find type initialization exceptions occurring because of project reference issues. The two most common causes:
Building your application against a newer version of .NET than the library being referenced (e.g. Protobuf library may have been compiled against .NET 4 while the application is being built against .NET 4.5). You could try resolving that by recompiling the Protobuf libs against the same .NET version as your project.
The compiler assumes a reference is present, but at run time it is not. You can fix this by adding a reference to the specific library (in this case the .NET library with the RegEx object, which is usually System.dll)
Related
I am trying to update a large solution to .NET Framework 4.7.2 with VS2019. One of the problems with this solution is that it is a large plugin type architecture, where (for many reasons) I am not able to recompile and release the plugins to production with the updated shared set of libraries that the solution provides.
Normally this is OK, but we have to be very careful to ensure full backwards binary compatibility. When we recently upgraded to .NET 4.7.2, we started getting conflicting usage indicators between System.Linq and MoreLinq, generally on the .ToHashSet() extension that we commonly use. The problem is outlined somewhat on MoreLinq's github
I think the only way to correct this is to isolate MoreLINQs usage into a single DLL that I control, and once all plugins reference that DLL upgrade to 4.7.2, fixing the .ToHashSet() call in the common location at that time.
Does anyone know of a better/more efficient way to do this, without re-releasing all the plugins at once? Some kind of global redirect that I am not aware of?
Evidently this just works. Installing the solutions common DLLs # 4.7.2 alongside older plugins # 4.5.2 worked fine, even though those plugins had compilation errors when compiling in Visual Studio against 4.7.2.
I'd be curious to know what internals are making this succeed. Does the system load multiple versions of .NET framework DLLs for the running process?
I've recently had to some work in Unity that required classes only available in the later versions of .NET, which Unity does not yet support. I managed to download the very few scripts that I was missing and added it to my project and it seems to work fine. What I wanted to know is why can I not just take the entire .NET source and shove it into my projects? What are the implications of doing something like that?
EDIT: The scripts that I have added so far was the generic version of WeakReference as well as any dependencies that it needed (Contract in System.Diagnostics.Contract).
EDIT EDIT: I basically want to know why I can't simply just the C# class files found in the later versions of .NET to Unity, which uses an older version of .NET. Is it a software issue? Is it a hardware issue? Is it because Unity's system components were built in correspondence with the earlier version of .NET?
SHORT ANSWER:
Install the Visual Studio Tools for Unity (it should automatically get installed when you install Unity), when you do you can tell your .csproj in the "target framework" drop-down to target the special version of .NET Unity uses and you will only be able to compile dll's that have methods and types that Unity supports.
LONG ANSWER:
It is because Unity does not use the installed version of .NET on your computer. Unity uses Mono, and a very old version at that. This allows unity to be ran on multiple platforms and OSes. Because of that you can only use features that are in the supported version of Mono.
However, if you look at their roadmap the alpha build you will see
Scripting: C# Compiler Upgrade
Upgrade Mono C# compiler against our
current .Net 2.0 and 2.0 Subset profiles. Note that this is an upgrade
of the C# compiler only, not the full Mono runtime
Then further on in the "research" phase
Scripting: .NET Profile Upgrade
Upgrade .Net profile to 4.6 enabling access to the latest .Net functionality and APIs.
UPDATE:
You can get a experimental build that uses the 4.6 profile from the stickied post here.
Here are the notes for the 5.6.0b5 beta release
For this release, the Editor and the following players should be working:
Windows, OSX, Linux standalone
iOS with IL2CPP
Android with IL2CPP and Mono
Other platforms are known to not work yet, and are probably not worth installing.
Managed debugging via Visual Studio Tools for Unity or MonoDevelop is not supported in this release. If you want to use VSTU for
editing please use the special build linked at the bottom of this
post.
The compiler targets the C# 6 language.
The compiler by default will still target the .Net 4.6 framework profile.
Known issues
The Android/Mono build does not work properly with managed code stripping. Please disable managed code stripping for now.
For some projects, the Windows standalone player can crash on Windows 8.1. This is intermittent, so we would love to see any crash
reports or data about this
A similar question was answered before here. Like I described in your other question, you can "inject" newer stuff and use them, but sooner or later they'll backfire (e.g. can't compile to particular systems, can compile but cannot be published in whatever mobile store, surprisingly slow execution, huge builds, etc. Worst case your project will be compromised).
If you really cannot refactor the project you are working on and you feel you must use 'up-to-date technology', bear in mind the injected classes code must be data objects, means, not at all related to GameObjects.It is also adviced to derive from ScriptableObject when and where possible.EDIT: But I'd recommend what I told you earlier (refactor) or what the linked answer describes ('export' the code incompatible with mono/.net2.0 to an external dll and use it from there)
I am creating a fresh Mono for android application using http://xamarin.com/monoforandroid
I selected Mono for Android Application using Visual C# option.
My Android target version is :
I went to references of the project and tried adding my pre existing dlls (made in .NET 4 Framework)
and I got this error:
The strange stuff is there is no option to change the .NET Framework from project properties. Can you tell me what I am missing?
The problem here is that you're trying to reference a .NET 4 DLL from a project that isn't .NET 4. Mono for Android uses its own profile for .NET, which is very similar to that of Silverlight (but not exactly the same). While it's possible that adding a DLL compiled for a different profile will work, it's very risky as you will probably run into problems at runtime where your app will crash, due to something being missing from the Mono for Android profile.
The best answer right now is to create a Mono for Android class library, link in the appropriate files from the library you want to use, and reference that. This will give you compile-time checking that you're not using anything unsupported by the Mono for Android profile, and help keep you more sane in the long run. I have an old blog post up here that talks about how to link files across projects.
That said, in this case you're in luck because someone else has already done that last part for you! Check out this fork of Json.NET which provides versions for MonoTouch and Mono for Android.
The strange stuff is there is no option to change the .NET Framework from project properties. Can you tell me what I am missing?
It's not particularly strange - that dialog box was written by Microsoft, with its own project types in mind. It sounds like Mono for Android doesn't have the same options available.
I strongly suspect you'll just have to use a version of JSON.NET targeting .NET 3.5.
(Having said that, Mono for Android claims to support "dynamic language features" which sounds like it should be targeting .NET 4. Odd. I suspect the fix is the same though.)
I'm writing an application in .Net 3.5.
I have 3 projects in the solution so far. When adding the references to the other projects from my main project, the intellisense manages to find the classes from the other project's dlls but at compile time it seems to be "loosing" the reference.
This might be because I initially created the project with target framework .Net 4.0. However since I needed to use the ASP.NET web services I had to downgrade to 3.5.
Any help will be greatly appreciated.
The referrenced projects must be Copy Local : True
Referrence -> Properites ->Copy Local : True
Batch clean all projects in your solution, make sure all the projects in your dependency graph target the .NET 3.5 framework. Check the reference's HintPath in your .csproj file (open with text editor) for references to external DLLs and make sure they're all <=3.5.
However since I needed to use the ASP.NET web services I had to downgrade to 3.5.
There are also several different web service projects in .NET 4. I don't quite understand this move.
You have project references, intellisense sees your referenced classes but when compiling, the compiler seems not to find the referenced assemblies.
I see two possible reasons for this behaviour:
Your main project references a lower version of the .NET framework than your library projects (this is the most likely cause).
Your library projects won't get built at all / or in the wrong order (check the settings in the configuration manager. Open it with a right click on your solution in the solition explorer).
i have an ASP.NET project written in Delphi.NET with Borland Studio 2006. Well it seems that the .NET Version is 1.1 and i need to port it to 3.5. My problem is that the project is a .bdsgroup and .groupproj. To make my work comfortable, i'd like to get a solution file .sln. What's the best way to this? (im not really sure i'm doing it all the right way. so if you have suggestions to make the port better, i'd please you to tell me)
thanks
First lets get a few things straightened out. Delphi.NET is both a language and a set of runtime libraries which attempted to recreate the RTL/VCL on the .NET platform.
Borland Development Studio is an IDE designed to edit multiple languages: Delphi, C++, C#, Delphi.NET.
If your intention is to port a Delphi.NET application to C# there are a few tools you can use. RedGate's .NET Reflector can generate C# from any .NET assembly regardless of the language that was used to write the assembly. I found it to be fairly useful at converting a Delphi.NET application to C#. Note: The generated code will still have dependencies on the RTL/VCL so you will still have to replace these with standard .NET equivalents.
If you are doing a Borland C# to VS C# port at least you're already in the same language. You'll just have to deal with library dependencies for the most part. If you already have the code working in BDS 2006 you can save yourself some trouble by replacing any borland-specific dependencies with standard .NET ones before you move to Visual Studio.
With proper separation of concerns and wrappers around third party libaries this is fairly straightforward. Unfortunately this is rarely the case. If your project is like most RAD style projects the business logic is embedded directly into the UI and library dependencies are directly woven into your code (this is rampant on any platform so don't think I'm singling out fans of Borland/Inprise/Codegear/Embarcadero). If this is the case you have your work cut out for you.
.sln file is Visual studio file, and not related to .Net or asp.net.
Delphi .Net has only support for .Net v2 (Delphi 2007), but you can switch your project to Delphi prism which support .Net up to verion 4, and work also from Visual studio IDE.
UPDATE:
I didn't know at first you are using C# project, so I gave my answer as Delphi, but if your project is c#, you can simply start VS and create new blank project, then add the *.cs from Project menu > add Exiting Files and point the *.CS files inside Delphi project, then save the Visual studio Project.
VS Doesn't read the *.bdsgroup files.