I am trying to implement the ProtectedData Class in C++ but are having some issues with compilation. My first error comes from not being able to use #using <System.Security.dll>. The error is that IntelliSense: "#using" requires C++/CLI to be enabled, however when I go into my project settings and set the common language runtime support to /clr, In my project I do not see my sytax errors getting corrected anymore. I then thought ok this must have fixed all the issues but then i go to compile and then I receive and error that '/clr' and '/Gm' command-line options are incompatible. So i go to look at this and I am not sure what to put to correct my problem. Is there any way I can use the ProtectedData Class without having to go through the different config process?
I am using Microsoft Visual C++ 2010 Express.
The link to the ProtectedData Class is here: http://msdn.microsoft.com/en-us/library/system.security.cryptography.protecteddata.aspx?cs-save-lang=1&cs-lang=cpp#code-snippet-2
Thank you for your time.
You could use Microsoft Visual C# 2010 Express instead. C++/CLI is best used only as a .NET/native bridging framework, and only when other methods of interoperation aren't suitable (such P/Invoke).
If you decide to use C++, you do need to use the /CLR switch. Although you can tweak a C++ project into a C++/CLI project, it's best to start fresh with the one of the CLR project templates.
Two ways to indicate that you want to use an external .NET assembly:
specify it with #using, or
add it to the References section of the project properties
Since you mentioned Intellisense, you'll find that it's not supported in C++/CLI code.
Related
I have a native Win32 project written in C and wanted to visualize my project's dependencies from external DLLs. Visual Studio 2012 and 2013 let me generate a code map which would not only show all my functions and their dependencies from each other using arrows, but also all external libraries I used, which functions I used from those and which of my functions called which external functions etc..
Now, in Visual Studio 2015, this latter part seems to be missing. I can not get Visual Studio to show my project's external dependencies. I only see the internal ones. So here's my questions: Am I missing something? Do I have to activate a specific option in my project settings? Or are those external dependencies just not working in Visual Studio 2015 right now?
Steps to reproduce: Create a new non-empty Win32-project. In the Architecture menu, select Generate code map for solution. You will only see Win32Project1.exe in the middle of the screen. Meanwhile, Visual C# seems to be fine, showing the external dependencies. Create any C#-project for comparison.
Thank you for taking the time to post this! This looks like a regression, as in Visual Studio 2013 an Externals group with external dependencies is shown for C++.
I've logged a bug on Microsoft Connect so that you're able to track this externally:
https://connect.microsoft.com/VisualStudio/feedback/details/1694695
I have posted this workaround on the link that Bogdan Gavril listed and hope it helps someone. Unfortunately, it requires that you enable "CLR" support for your project. Basically, it appears that the VC++ linker and librarian is looking for a flag that indicates some type of managed code. At the very least, the code map is dependent on the mscorlib.dll reference injection. To make the CLR issue (which adds a lot of unnecessary bulk for native code) less a problem, simply create a new build configuration for use only when you need code maps with external dependencies. Make sure you've selected "CLR Support" on the general options of the project properties configuration page. Then, clean (probably not necessary) your solution and generate a code map. You will find the external dependencies as expected!
Zac
Is is possible to use Dreamweaver to create Typescript? either as an editor or in some fashion to compile?
I don't think you will be able to get the full TypeScript experience in Dreamweaver. The beauty of tools like Visual Studio or Web Storm is that you can design-time support, compilation-time checking and compilation to JavaScript all built in.
I can't find any documentation for the two major things you would need to bring TypeScript support to Dreamweaver:
Language support extensibility (a language definition of some kind)
Running an external application on save (to run the compiler)
You could probably get enough just with language support by running the compiler manually (probably by adding the command to a batch file) - but I cannot find any information on how to add a language to Dreamweaver.
I am working on a C++/CLI project with VS 2012 in Dynamic Library (.dll) and x64 mode.
If I switch the mode to Static Library, I get the error below.
Error 1 error C1107: could not find assembly 'mscorlib.dll': please specify the assembly search path using /AI or by setting the LIBPATH environment variable C:\Depot\Main\Current\Sln\ALibraryProject\Stdafx.cpp 1 1 ALibraryProject
I tried removing the reference to the mscorlib.dll then adding it again from:
Project > Properties > General > Common Properties
But that didn't help. As I know that VS handles the reference to the .NET assemblies, I don't want to add a disk file reference to it as it seems illogical! Did anybody face this before?
I had the same problem when converting my solution from the VS2010 compiler to VS2013 compiler.
I resolved it by changing the project settings (for the project containing the managed .cpp file that was throwing this error) as follows: In Project Settings | C/C++ | General | Additional #using Directories I added the macro $(FrameworkPathOverride). This resolves to the reference assembly directory for the version of .NET that you're targeting, which in my case is C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5.1
If I switch the mode to Static Library
This is not the typical error you get when you try to build a static library with /clr in effect. I'd have to assume you've been tinkering with project settings to get rid of the inscrutable linker errors you get when you try to do this.
Core issue is that the C++/CLI build system doesn't support static libraries that contain MSIL. Managed code doesn't use a linker, binding happens at runtime. Which makes the essential difference between static libraries and DLLs disappear. So Microsoft decided to not support it because it didn't make much sense to implement it. Unfortunately they don't yell loud enough when you try to do it anyway, the linker errors you get don't give enough of a hint what you did wrong. Workarounds, like merging with ILMerge don't work either, it cannot deal with mixed-mode assemblies. Merging the native code sections and their associated relocation table entries is very untrivial.
Keep in mind that it is fine to link native static libraries. A typical C++/CLI project has only the ref class wrappers that need to be built with /clr in effect. You can glue any amount of native code from libraries into the final assembly.
I'm forced to theorize about the actual compile error, too many programmers get this error for another reason that doesn't have anything to do with building static libraries and they are harassing me in the comments.
Do beware that targeting a different version of .NET than the one you have installed on your machine is quite a hazardous affair, particularly so if you want to target 4.0 and you have 4.5.x installed. The key element in your .vcxproj file is the <TargetFrameworkVersion>. This will be missing if you started the project targeting an old .NET version, you have to insert it yourself. The IDE also doesn't support changing it if it is present, again edit by hand.
Which is enough to coax MSBuild into generating the proper compile command. You can verify if that panned-out well, look in the *.tlog subdirectory of the Debug build directory for your project. The cl.command.1.tlog file shows the options that were passed to the compiler. It should contain:
/AI"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0"
/FU"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\mscorlib.dll"
Note the subdirectory, very important that it matches your intended .NET target. v4.0 in this example. And very, very important that it does not point to c:\windows\microsoft.net, the legacy location for reference assemblies.
I have the same problem. Having a dll doesn't work, as I need to provide a native C++ wrapper for a .net object so it can fulfil a natice c++ interface - I can't use .net in a dll interface - this gives a compile error
This worked as a static library in VS 2010 (with .net 4)
Some of my executables and dlls which also have some code with /clr. They don't have an issue. I'm not trying to make a net Lbirary.
I solved it by removing dependency in old and not updated mixed lib, which was also configured only in Debug configuration, and as result, it started to get the same error as yours after I changed some code.
It was not simple to find it, because error is not clear, and the dependency was set up via "Additional Dependencies" in project settings.
Open visual studio and unload your project then Go to the project folder and open file .vcxproj . Search for tag "targetFrameworkVersion"
(if not present it means ur project is not using dot net frameworks.so no requirement of change)
Change it to required version
Save the file.
And now reload the project .
How would I go about using F# or J# for instance? I'm not sure what to get to grips with in the project's compiler settings.
Is there a sequence of command line steps I could follow to compile a MonoTouch project that I might interpret to replace the C# step but tell the other compiler to use the correct platform details etc?
Thank you.
Unfortunately, no. In the book "Developing C# Apps for iPhone and iPad using MonoTouch" you could see text (proof):
C# Is Currently the Only Language
Additionally, currently, the only .NET language available for writing MonoTouch applications is C#.
Nothing changed since that book publication.
Maxim Korobov is right, MonoDevelop only supports C# when writing for MonoTouch.
But this is not the whole truth: MonoDevelop also has (preliminary) support for Portable Library Projects (PLP). What this means is that you can create and compile PLP projects in Visual Studio (in any language Visual Studio supports for PLP projects), and then reference that library in MonoDevelop. Just have in mind that the PLP support is preliminary right now, and you might run into a few bumps on the way.
I am reading up about linking native libraries into MonoTouch, specifically this documentation:
http://monotouch.net/Documentation/Linking_Native_Libraries
Here it describes linking to C libraries. Is it also possible to link to C++ libraries from MonoTouch? I am very new to MonoTouch and particularly to importing libraries, so I would appreciate any advice about problems I may face trying to import a C++ library, if this is indeed possible. Would wrapping the C++ library in an Objective-C library and then using btouch to import this be a good route to take? Or is there an easier approach? Bearing in mind that my knowledge of C++ (and Objective-C for that matter) can best be described as "dangerous". ;)
The reason that I ask is that I am needing to make use of a C++ API from Sybase to access their Ultralite database. I have managed to get a sample application that accesses the Ultralite C++ API working in Xcode, with Objective-C. But now I am trying to port this sample to MonoTouch. The sample application can be found here:
https://github.com/BruceHill/Ultralite-Names-Sample-ObjC
The Sybase documentation for Xcode mentions the following, with reference to using the API in Xcode:
This tutorial uses the UltraLite C++ API. In order to eliminate the need to cast to C types, compile the source as C++. To compile the project as C++:
In the Search in Build Settings box, enter Compile Sources As.
Choose Objective-C++ from the options in the Value field
What are the implications of this for working with this API in MonoTouch?
You can certainly use a C++ api, but you will need to either wrap it in a C api, or a ObjC+btouch api to be able to talk to this. Invoking C api's uses PInvoke, and C++ libraries use symbol mangling. While theoretically you could pinvoke to the mangled symbol, this isn't a good idea as the mangling is compiler specific.