I'm new in monodevelop and I have a question.
I have some assemblies developed in Visual Studio 2010 in C# and I would like to use them with monotouch in Mac, my question is: do I have to use the source and generate the assemblies with monodevelop in Mac or just I need the assemblies and add them to my solution as a reference?
The framework profile used by MonoTouch was originally based on the Silverlight profile (aka 2.1) and was updated to include some, but not all, of the new API provided by the .NET framework 4.0.
As such you might be able to reuse assemblies, without recompiling them. That will depends if all the API are available, if you refer to assemblies not available in MonoTouch, under what profile (3.5 or 4.0) you're building the code...
However things would be a lot easier if you have the source code and are able to re-compile it inside MonoDevelop. That would provide you with debugging symbols (the .mdb files) also also catch, at compile time (not at run time), and fix code using any missing API (from MonoTouch).
You should be able to use the same assemblies as they are (no need for a recompile). If the assemblies depend on other nonstandard assemblies it might get tricky and you may have to deploy other assemblies along side the ones you want and then that may cause it's own problems if they are not open source or licenses are required to redistribute, etc.. Give it a shot, see what happens.
Related
Disclaimer: I have only two day's experience trying to learn modern MSBuild techniques, but have used C# and VS for many years largely avoiding project file details outside of what the UI provides.
I am creating experimental DLLs that intentionally name-match and somewhat interface-match several of those found in the .NET Standard. For instance a custom System.IO.dll may partially match the public interface of .NET's System.IO.dll, same with mscorlib.dll, etc.
The goal is to be able to create a new C# project (File->New->Project->...) and have it link to these alternatives DLLs and not the official DLLs. This has been done successfully from the command-line using csc.exe, but not yet from within VS.
Using detailed build output verbosity in VS (Tools->Options->Projects and Solutions->Build and Run) shows that the numerous DLLs within .NET are added to the csc.exe command-line. Perhaps if this could be prevented all would be well. One failed attempt to do so involved removing the <TargetFramework> altogether.
Maybe registering a "custom framework" with Visual Studio would allow a custom value to be used within csproj, e.g.<TargetFramework>mydotnet</TargetFramework>?
All just guesses.
It seems MSBuild is very rich and would allow for multiple ways to achieve such a thing. I am completely receptive to learning one or more of these techniques, since one may provide advantages for future build customization plans.
How can a Custom Framework be used instead of .NET in Visual Studio for C# projects?
To use a Custom Framework instead of .NET in Visual Studio for C# projects, you have to do a lot of things, Registering Framework, Create a Template for Project and so on. So, Are you really writing your own implementation of the framework? If you just want to add your own libraries to an existing Framework, you can refer to following thread:
Registering Extensions of the .NET Framework
Besides, there is a document about How to: Add a Custom ASP.NET MVC Test Framework in Visual Studio, you can check it for details.
I have an independent solution with multiple projects including class libraries and control libraries. This solution and all its projects are under TFS source control.
I reference the output of one or more of these libraries in all new projects I develop. References are currently binary rather than project references.
The new projects are also always under source control and now I need to add debugging support for the libraries.
If I reference the library projects from them, the project file is modified and no longer works with the original library solution since source control providers for the library and referencee may be different.
Is there an easy way to accommodate this?
You should package the shared binaries, along with indexed PDB's, into a Nuget package. Nuget was specifically designed to solve these problems.
You can index your PDB's by running an indexing tool. TF Build can automatically index your PDB's.
Nope.
There are some strategies you can use, however. Easiest (possibly, but not in some cases) is to build the project you wish to debug, drop the binaries on top of the application that hosts them, and attach your debugger to the running application. This makes sure you have the correct version of the assembly under debug, but you might have to do unwanted things, such as making sure you're not targeting a specific version of the assembly
Which may be bad news for an assembly under development. It also requires lots of handiwork, which depending on where your application runs may require you run remote debugging, deal with issues transmitting dlls across untrusted networks, etc etc.
I am making a small external tool for Visual Studio that uses the following referenced assembly:
Microsoft.TeamFoundation.VersionControl.Client
My tool is built in Visual Studio 2012, so it uses the reference of that same version, 11.0.0.0. When I try to run the same tool in Visual Studio 2013, the file is missing because the version has changed in VS2013: 12.0.0.0.
Note that this happens when only Visual Studio 2013 is installed on the machine.
What I am trying to achieve now, is to have my program use the version that is available on the machine. So if the version 12.0.0.0 is found, use that; and if 11.0.0.0 is found, use that.
After some research I came across this link which said the following:
To successfully deploy your .NET Framework application, you must understand how the common language runtime locates and binds to the assemblies that make up your application. By default, the runtime attempts to bind with the exact version of an assembly that the application was built with. This default behavior can be overridden by configuration file settings.
This can be achieved by the use of a dynamic reference, as explained in that same topic.
While there is information on how to dynamically load references, I am unsure how to approach this.
Based on this I have some questions:
Is there any way for me to add one dynamic reference and have the machine it runs on decide which version it uses?
Are there any other ways to achieve the use of two versions where only one may be used on the machine?
Would an option be to build the application on a machine with VS2012 AND VS2013, and reference both versions?
Edit: Option 3 is not possible because Visual Studio complains about a reference to that component already existing.
Edit 2: If I add the reference as follows:
<Reference Include="Microsoft.TeamFoundation.VersionControl.Client" />
without the use of Version, Culture, etcetera; I get a compilation error saying there is a conflict between different versions of the same dependent assembly.
Edit 3: Setting the referenceversion to non-specific does not work either, as this is a buildsetting and not a runtime setting.
We are developing an add-in for Autodesk Inventor. Our software is a bunch of dll assemblies loaded into Inventor at runtime. We have decided to use the Microsoft Enterprise Library 5.0 for logging and exception handling.
Now we have a problem, because it turns out Inventor 2013 uses Enterprise Library 4.1. When our add-in is loading, it fails to load the proper version of an assembly, because Inventor already has an older version in its Bin directory.
Options we have considered so far:
During deployment of our product, overwrite the old libraries in Inventor's Bin folder
Use EL 4.1 in our assemblies
Both are bad and I'm running out of ideas, so I'm asking for help.
Option 1 raises this question: is the Enterprise Library backwards compatible and will replacing those DLL's in the Bin folder cause problems? I have tried it, Inventor doesn't complain and works as expected (haven't checked the EL functionality).
Option 2 makes us use the older version and binds us to the version Autodesk is using, so we would have to watch when they upgrade, especially when they release a new version of Inventor.
What is the best practice in this scenario?
UPDATE:
We solved this by just putting the newer version of Enterprise Library in GAC. I think what happened here was that .NET tried loading the older version first (because it was higher in assembly search order) and after failing never went any further to look for the proper version. When in GAC, it correctly resolves.
From what I can see, a reasonable solution would be to embed the assemblies and access them using the ResourceManager class, this would allow you to use the newer versions whilst maintaining the parent projects logging mechanism.
You might find this question useful:
Embedding assemblies inside another assembly
I have been recently trying to deploy a C# application on a computer that does not have .NET installed.
I know that there have been many questions around the same topic here on StackOverflow. Here are a few of them, of which I read the responses to all:
Packaging up the .net framework with a .net application deployment
Run a .net application without installing .net client profile?
Run C# windows application in windows XP without installing .NET Framework
So all of the responses to the above questions state that it is impossible without specific software, etc. One software mentioned was the Salamander .NET Linker. The only problem with that is that I cannot seem to be able to run the application after it has been processed by Salamender. I understand that this in itself is impossible, as it requires the .NET virtual machine to run. However, in the past, I have made Java applications and along with them, I shipped the entire JVM. Surprisingly, they still worked. So the reason why this is not a duplicate of the above questions is because my true question is:
What items of the .NET framework would I need to package? If I do manage to package all, would placing them in the same directory as the application I'm running allow the application to run?
I found one solution to this, the Microsoft .NET Redist Package. The only problem with this is that it has a GUI of its own. Aside from that, it would be a perfect fit. So, could anyone tell me one of two things:
Is there a command-line .NET package, and if so, where do I download it?
If there isn't, or it would be impractical to do so, approximately what directories would I need to copy from the .NET installations?
I understand that these files and directories are system specific, and that my .NET installation may not work on your computer, but if C# is like Java, then this should be achievable. Is it? Size is not a limitation, it does not matter to me whether or not the application and all its files is 1GB, or if it is only 1MB.
If in case there is no other solution, I used Dependency Walker to check all the dependencies of my program. If I were to package most of them, would my application, in theory, work?
For .NET, you really must just install the appropriate .NET framework. The .NET framework installation does include command line options to allow for silent installs, such as:
dotnetfx35.exe /q /norestart
For details on the command line options, see the options for 3.5 and for .NET 4.0.
That being said, most installation packages will handle these details for you as part of the installation. Using a decent installer will take care of this dependency automatically.
Depending on the pieces of the .NET Framework you need, you can use Mono. It supports shipping the runtime without installing just like you would a JVM, or you can statically link against the binaries to create a native executable .
If you are planning to deploy your application (and presuming the setup process doesn't need to be too complex), you can simply create a Setup project in Visual Studio and then bootstrap the prerequisites (.NET framework, and other stuff you think you might need).
You can follow the steps described in these MSDN articles:
How to create a Setup project in Visual Studio
How to add prerequisites to a Setup project
A walkthrough is given in this CodeProject article.
For more complex deployment scenarios (such as installing device drivers along your app, or better localization support), I would recommend looking into WiX (Windows Installer XML) toolset. It's a toolset that builds Windows installation packages, which you configure using XML files inside Visual Studio. WiX also supports various bootstrapping scenarios.
This page covers the differences between VS Setup projects, WiX, and InstallShield.