I'm using the latest version of SubSonic (3.0.3). I'm having a problem with building my solution when my assembly is signed. I get an error stating the 'SubSonic.Core' assembly does not have a strong name. Can I not use SubSonic with a signed assembly?
You will need to rebuild the SubSonic.Core assembly in a way that it gets a strong name/signed.
See also:
Why can’t strongly named assemblies use assemblies that aren’t signed?
Related
We have a Visual Studio solution with about 90 projects. Most of them are built to DLL files, some are written in C++, others in C#. The projects communicate with each other via COM. We use tlbexp to generate TLB files of some C# projects (the ones that are referenced in C++ projects). And we use tlbimp to generate interop DLLs of the C++ projects. I did not completely dig into the topic, but I think, the interop files just define the interfaces of the C++ classes, to make them usable from other projects is that right?
Now, the question is the following: In order to upgrade the entire solution to Visual Studio 2015 and let it compile against .NET 4.6.1, I inspected the resulting assemblies using dotPeek by JetBrains. I can see, that all the C# projects are correctly using .NET 4.6.1, the C++ DLLs themselves are native and do not reference any .NET. Now, what surprised me was the fact, that dotPeek told me, the interop DLLs (which resulted from the C++ projects), were referencing .NET 4.0.
After a "wonderful" day of trying to make them reference .NET 4.6.1 and lots of research, I finally did not find any way to make the interops reference .NET 4.6.1. Is that even possible? My current guess is, that all interop DLLs generated like this reference just the basic .NET 4.0, just because it uses the same CLR as .NET 4.6.1.
Is that right? It should be possible to execute the assemblies on any system that has .NET Framework 4.6.1 installed, shouldn't it?
You are getting bad info from dotPeek. It doesn't tell you how it figured out what .NET version is targeted. It can be specific on a .NET assembly that's generated by a compiler. Because it automatically inserts a [TargetFramework] attribute into the assembly, it states what version of .NET you selected when you built the project.
But an interop assembly does not specify a .NET version, primarily because it isn't generated by a compiler. Note how you never specified a version when you ran Tlbimp.exe. And can't. All that dotPeek can figure out is that it targets .NET 4, cued by the metadata format. No way it can be more specific.
And it does not matter, since the interop library does not use .NET Framework features. The only point of the library is that your program can use the COM component features. So the version number that dotPeek reports just doesn't matter; any .NET 4.x framework can use the library.
You don't have a real problem.
Anyone have idea to develop FMILibrary(64 bit) for PyFMI package.
FMILibrary(32 bit) compiled successfully with PyFMI package.
thanks for your useful ideas in advance
There is nothing that needs to be done on the FMI library side to be able to compile it as 64bit. You need to grab the source from http://www.jmodelica.org/FMILibrary and use a C-compiler that supports 64bit then you are good to go.
A similar problem was encountered also here.
As for the FMILibrary, as far as I understand, it is nothing you have to compile with PyFMI. It is a prerequisite for the operation of PyFMI. What you need to do is compiling FMILibrary(check the required version for PyFMI from here) using a compiler. And do not forget to show the path of FMILibrary to PyFMI.
What I would suggest, as in the first link stated, is installing Anaconda and working in a created environment.
I tried to follow this question and answers but have gotten lots of compilation errors like this.
error C2182: '__formal' : illegal use of type 'void'
Is there anybody who is successfully using VS 6.0 with Google Testing?
Some time ago, someone proposed a patch for Google Test to support VC6. That patch was ultimately rejected in the trunk because it made it harder to support the library. But the patched source was put in a branch in Subversion for people who need it. There it sits, unsupported.
But because it's not supported, there has been no backports from the trunk since it was branched at version 1.3. But if you really need it and don't mind missing all the features added since then, you can grab it from there.
Probably not. VS 6.0 isn't compatible with C++03, so not much C++ will work on it. You'll most likely need at least VS 7.1 (2003) or VS 8.0 (2005).
I have a VS2008 Professional solution that I tried to convert to VS2010 Professional (RTM from MSDN download) today and I am experiencing some problems with some unmanaged and managed C++ DLLs that are referenced by a C# application.
The C# application is set to target .NET 3.5 (as it was in the VS2008 version) but when I try and compile it I get a lot of warnings like:
The primary reference "xxxx.dll" could
not be resolved because it had an
indirect dependency on the .NET
Framework assembly "(various assembly
names)", Version 4.0.0.0 ... which has
a higher version "4.0.0.0" than the
version "3.5.0.0" in the current
target framework
and ultimately I get a failure to build.
From this I understand that it is a mismatch in .Net framework version. So I look at the properties of the unmanaged C++ DLL project and under "Common Properties->Framework and References" I can see "Targeted framework: .NetFramework, Version=v4.0"
So I go WTF!?!?!?, why does a pure C++ DLL now target a .Net framework when it sure as hell didn't in the VS2008 version. I then added on to that exclamation as there appears to be no way to change this. I also look at the managed C++ and see the same thing: targeting .Net version=v4.0 and again no way to change this at all.
In the C++ General properties there is an entry for "Common language runtime support" and I have set this to "No common language run time support" but that hasn't seem to have done anything.
So I have two questions:
Why has my pure C++ DLL now been tagged as targeting a .Net framework?
How can I change/remove this targeting?
Solution
As per Hans' reply and the link he supplied I now see that I have 3 choices:
Stay at VS2008 and everything works
Keep both VS2008 SP1 and VS2010
installed so that I can have .Net
3.5 c# applications and c++ managed code as per the link supplied by Hans.
Move everything to VS2010 and move
to a minimum of .Net 4.0 for all my
c# apps
I am really annoyed to have to make that choice as MS has deliberately chosen to break functionality when moving from VS2008 to VS2010. This is not the sort of behavior I expected. I was expecting to convert the project and have it compile with no issues in the same manner that moving from VS2005 to VS2008 worked.
Fortunately I do have a need to go to .Net 4.0, but I just wasn't expecting to have to do it so soon.
Update
I decided to move to .Net 4 framework and encountered problems with referencing managed c++ projects from c# projects. I was getting errors like the following when trying to add the reference to the c++ managed code project
A reference to 'myproj' could not be
added. An Assembly must have a 'dll'
or 'exe' extension in order to be
referenced.
Google lead me down the path to "cli c project cannot be referenced from c project allowing only assembly dll" which turned up that there was an extraneous "\" in the output path of the managed c++ project. The original VS2008 output path was specified as
$(SolutionDir)\$(ProjectName)\$(Configuration)\
But in the VS2010 project the SolutionDir macro has a trailing "\" (or the VS2008 version didn't care about it) giving a path like
c:\projects\thisproject\solution\\projectname\configuration\
And VS2010 barfed over that path when trying to add a reference to the managed c++ code. My solution was to change the output path to be
$(SolutionDir)$(ProjectName)\$(Configuration)\
And now I am (sort of) happy
Keep your eyes on the ball, the warning you get is for a managed C++ assembly. And the platform target setting for an unmanaged DLL is of no consequence, it won't use any .NET references while being built.
Yes, they could not make the platform target setting editable in the C++ IDE, the VS2008 tool chain is required to build C++/CLI assemblies for 3.5. This blog post explains the workaround. You can upvote this feedback article if you're unhappy with that.
I'm using Visual Studio 2008 for C++. When compiling, Visual Studio compiles against the header files of the VC 9.0 libraries. However, there are different versions of this library available:
v9.0.21022.8 (= RTM)
v9.0.30729.17 (= SP1)
v9.0.30729.4148 (= SP1 with security update)
I'd like to know whether it is possible to tell Visual Studio which version it should compile against.
The reason I think this is important is because the application's installer needs to make sure that the correct version of the Microsoft Visual C++ 2008 Redistributable Package is installed. To me it feels like I don't have any control over this dependency, as apparently some Windows Update (not a Visual Studio update) can change this dependency. I'd like to keep using the same version to avoid the overhead of making the installer upgrading the Redistributable Package.
Note that this situation is different from my earlier question, as that one was about link time. Neither am I looking for a way to control the version that is put in the embedded manifest file, as that is explained here.
The manifest that's included with your binaries is automatically generated by the VS build system. Important headers that determine the version dependency that's emitted into the manifest are vc\include\crtassem.h and crtdefs.h. The former declares the CRT version. Note that it already has support for the RTM version vs the "latest" version with the _BIND_TO_CURRENT_CRT_VERSION macro. The latter contains #pragma comment directives to embed the /manifestdependency linker option into the .obj file, which in turn makes the linker auto-generate the manifest.
You don't have to do it this way, you can simply turn off the linker options that generate the manifest and write your own. That gives you complete control over the CRT version that your app binds to. Whether you are ahead with this is a bit questionable. You would probably still be shipping the old version of the CRT that got updated in July of last year, it contained a critical security bug. Customers tend to be a bit unhappy about getting software installed on their machine that has well documented and solved security flaws.
The next thing you'd have to do is take control of the deployment of the DLLs. You'll have to deploy the DLLs into the WinSxS side-by-side cache yourself.
That will work, if you figure out how, but it isn't likely to survive for very long. Windows Update, if enabled, may discover that the machine is using an unpatched version of the DLLs and will update it. And deploy a publisher policy to redirect load requests. It is likely that your machine has such a policy file in place if you see your manifested version request resulting in the load of another version. The somewhat unescapable conclusion is that this is MSFT's DLL and they'll do with it what they think is necessary. Look at applocal deployment to avoid this.
It's this just a question of which directory your configuration is set to build against. As long as you have all the versions of headers on your machine and the libraries they link against I don't see why this can't be a new configuration for each version.
If the issue is things like SP1, there's not much you can do. Microsoft considers the runtime, in effect, a component of the operating system. It therefore gets updates and patches the same as any OS component.
There shouldn't be a problem with this, normally - the patches are bugfixes and security updates after all. In principle, each change should make your apps more stable. Not quite always true, but in any case there isn't much you can do about it.
There are options to change the runtime, but they are related to thread-safety and similar issues. There's a few relevant places in the project properties. In particular, in the C/C++/Code Generation tab you can select which run-time library to use.
If you are seriously worried, you can choose a statically linked non-DLL runtime. Users can still update their runtime DLL, but it won't improve the stability of your app when they do so.
You can do this using manifest resource files, which are written in XML.
We had to do this at a previous place of employment, unfortunately (or perhaps, more fortunately), I was not exposed to the in depth details of how it was done. This article looks about the closest to what we did that I could find on the subject.
Update0
Here is MSDN documentation regarding manifest file generation, and their use in isolating applications and building side by side assemblies.