I have some code to compile at runtime as a script and setup file. I know on windows you can use Microsoft.CSharp and System.CodeDom.Compiler to compile code at runtime. And I just want to know if these two namespace exist in mono(I'd like to make a app I'm making sort of cross-platform). I couldn't find a mono api reference which means it has almost everything that .net has?
thanks!
Related
I have a DLL written in C# and set for COM visibility. I have it setup as a side-by-side assembly and can successfully deploy the application to client PCs registration free. My question is related to the development PC. Is it possible to compile against the DLL in a similar registration-free manner or is registration required on the development machine? I have tried adding the DLL directly though the Project -> References menu and get an error stating "Can't add a reference to the specific file." The DLL is sitting in the same directory as the .vbp file and I have tried adding the DLL both with and without the client app manifest being present.
I have tried adding the DLL directly though the Project -> References menu
That adds a reference to a type library. A type library is a language-independent description of the types in a COM component, VB6 uses it to know how generate efficient code and to provide type checking and auto-completion. A type library is the exact equivalent of metadata in a .NET assembly.
Traditionally, and the way VB6 did it, the type library was embedded as a resource in a DLL. So you are probably used to picking a DLL in the dialog. That however doesn't work so well when the DLL is generated by C#, the type library can only be generated after the C# code is compiled. You have to pick the .tlb file in the VB6 dialog. The traditional way starts with the COM component being described in the IDL language, the type library can be generated before the code is compiled so can easily be embedded in the final DLL. It is technically possible to do it in C# as well, but the build steps are very laborious and painful, you essentially have to build the DLL twice with different build commands.
The type library for a C# library is normally generated in one of three ways:
Using Project + Properties, Build tab, "Register for COM interop" option. This requires VS to run elevated so it can write to the registry. You start VS elevated by right-clicking its shortcut and picking "Run as Administrator"
By running Regasm.exe, using the /tlb:filename option. An alternative for the 1st bullet and necessary if you don't want to run VS elevated for some reason. Using the /codebase option on your dev machine is also wise to make it work exactly like the 1st bullet and not require putting the DLL into the GAC with gacutil.exe
By running the Tlbexp.exe utility, the type library exporter for .NET assemblies. No registration is done, it only generates the .tlb file.
The first bullet is the normal choice and very desirable because you can never forget to update the type library this way. It is perfectly fine on a dev machine since you only really care about reg-free deployment on the user's machine. You probably got into trouble by not doing this anymore.
Using the 3rd choice is okay and more compatible with your goals, run Tlbexp from the Visual Studio Command Prompt. Just keep in mind that you have to do it again when you make changes to your C# code. Forgetting this once and losing clumps of head-hair trying to figure out why your C# changes don't seem to be effective or getting hard-to-diagnose error codes gives you lots of reasons to consider the 1st bullet again :) You can emulate the reg-free scenario by running Regasm.exe with the /uninstall option.
I am in the process of writing a .NET wrapper for legacy native c++ code. My strategy is to write a CLR class library that wraps the native code.
To test whether the class library is functioning properly, I created two console apps in separate solutions:
A C++ CLR console app
A C# console app
Both of these contain the same simple test code to exercise the class library.
Both apps build as expected. The C++ app runs just fine, but the C# app is giving me a FileNotFoundException when it tries to load my class library.
I have a constraint that forces me to use VS2008 and .NET 3.5. Everything is built with Win32 or x86 configurations.
For both console apps, I am using a project reference to the class library.
In each case, builds copy the dll (and the intermediate files) to the same directory where each app is built.
I tried using the fusion log viewer, but logs are disabled on my machine and I do not have administrator privileges.
Has anyone ever seen this before?
Can someone please point me to a good site that outlines the differences between the way C# and C++ CLR apps load assemblies?
Since this is my first attempt to bridge C++ and C# I assume I am just making a simple mistake somewhere, but I am stumped as to what that is.
I have trolled the internet (including many SO postings) but have yet to find exactly what I need.
Thanks in advance,
Judd
I am trying to troubleshoot a VB.NET project that contains UserControls (actually, several of them that are displaying the same issues). I am trying to get them to build under x64, but it is impossible. In x86 or AnyCPU, the UserControl builds and shows up in the Toolbox, so I can add or modify it in the forms that require it. In x64, the controls disappear from the Toolbox, I get warnings during build (the current project builds though), I can't see any of the forms - I get errors (please see below) - and projects that require the project with the form as an import will not build.
When I was studying what these UserControls are so that I can maybe rebuild them from scratch, I downloaded code from a book - great learning tool, but I get the same errors:
Could not find type 'Chap15SampleCode.ListSelector'. Please make sure that the assembly that contains this type is referenced. If this type is a part of your development project, make sure that the project has been successfully built using settings for your current platform or Any CPU.
The variable 'ListSelector1' is either undeclared or was never assigned.
I also get warnings, not sure what to do about them:
Possible problem detected while building assembly 'Chap15SampleCode': Referenced assembly 'mscorlib.dll' targets a different processor
Possible problem detected while building assembly 'Chap15SampleCode': Referenced assembly 'System.Data.dll' targets a different processor
I checked and found System.Data as a Reference is in c:\Windows\Microsoft.NET\Framework... (if I change the target framework to 4.0 the Reference is in c:\ProgramFiles(x86)... that was what my projects had ... and I tried to change it because of the x86, I couldn't, I had a few others in ProgramFiles(x86) and I thought that may be the problem ?)
Reinstalled VS2010, reinstalled Windows - did the same before btw - but I do have a clean system so I can't blame it.
If I can get this simple project to work, I hope the real projects will be easy - Please help me figure out what this is about. Thank you.
You have changed the Platform target setting in the project to x64. This is not appropriate for any project that produces a DLL. The actual bitness of a process that uses your DLL is determined by the EXE that starts the process. Or the host in which your DLL runs, the case for Visual Studio which is a 32-bit process. There is nothing a DLL can do to force the bitness, it can only refuse to get loaded. Which is what you see happening.
Change the setting back to AnyCPU so that your UserControl will work correctly in any process, regardless of its bitness. Including the VS designer. Project + Properties, Build tab. For VB.NET it is located in the Compile tab, Advanced Compile Options button.
The big picture: what I am trying to accomplish is writing code in both C# and C++, to strike a good performance/productivity balance. It is not for code reuse reasons; I just want to be able to write new code in native C++ when it suits me, without committing to all its horrors.
I have a solution with 4 projects:
GUI: C# WPF interface
Logic_Cs: C# DLL, high level reference implementation of game logic
Logic_CLI: CLI DLL, interface between managed and unmanaged code
Logic_Cpp: C++ lib with native implementation
At some point, all of this was working just fine. In my GUI project I could switch between C#/C++ implementation merely by using the namespace from the appropriate DLL.
Then I apparently changed something, and now I can not get the namespace in the Logic_CLI project to be recognized in the GUI project, even though the Logic_Cs namespace still works just fine.
Yes, I added correct references, set dependencies, rebuilt AND recreated my entire solution structure from scratch; nothing helps.
I notice the C# DLL builds to a folder in its own project directory, while CLI builds to the solution directory; but the GUI application seems to look for the DLL's in their correct directory anyway, and im not getting any complaints about the DLL; it just refuses to import the namespace from it.
Earlier, when all this was working, I wasnt explicitly exporting anything from the CLI DLL; nor am I doing so for the C# DLL. It should 'just work', no?
hope someone is using Mono & monodevelop...
i'm getting the following error when i try to compile an ASP.NET apps ported from vs.net 2008
Error VBNC99999: Unexpected error: The classes in the module cannot be loaded. (VBNC99999)
This is the only error i get.
I'm using 4 external assembly / dll
AjaxControlToolkit.dll
FusionCharts.dll
MySql.Data.dll
PostBackRitalin.dll
I've added the dll in bin directory, then i've referenced it.
I'm using Mono, because on my "old" computer (acer aspire t2300 buyed in 2007) run with linux & with monodevelop very well.
With windows, visual studio is reeeeeeally slow.. so i decide to pass to mono..
Can somenone know something about that error ?
Thank you very much. Regards !
I can guess a few possible reasons, though it's hard to be sure without more info.
The Mono VB.NET compiler is only a VB8 compiler (VS2005), so if you're using VB9 features that might explain the problem.
One of the libraries you're using might be a mixed-mode binary, and contain native Windows code.
You might have found a bug in the VB compiler. If you think this is the case, you should file a bug report.
Beware that Mono's VB.NET compiler is nowhere near as actively developed and tested as the C# one, and MonoDevelop doesn't have code completion or refactoring for VB either. I generally recommend that VB devs compile on Windows and copy the binaries over to Linux, or learn C#...