I'm running VS2010 Version 10.0.30319.1 RMTRel
I've noticed problems compiling VB.NET application. When I "rebuild" the solution it reports the build was successful. When I then click the run icon to begin debugging, then the compiler will report build errors(often related to referenced projects). I've confirmed all the projects are targeting the same framework and after an undeterministic number of times repeating the same steps, it will eventually compile. This seems consistent enough to me with other code bases to believe that it's a problem with VS. Anyone have any thoughts that might help improve my experience?
You should also check your configuration manager - probably some of projects are disabled for building in current build plan.
is this a rather large solution? If so, the order of build may be out of whack and the way to solve that is to set the build order of the projects to make sure all of the dependent projects are built first.
One common reason is circular references. You cannot do this in a pair of projects, but it can be done if you cobble together a long string of projects. The way to catch this is a dependency mapping tool with a visual representation of dependencies. You will see the items that refer back up to the top.
Related
This seems to be a tricky question, also because it is difficult to present here all settings involved. So let me state the total picture:
I use Visual Studio 2022 to build a solution (all in x64 mode) comprising of two projects
CapopConsole
and
CapopWrap
CapopConsole is a C# Console-Project generating an exe and CapopWrap is a C++/CLI project wrapping a C++ native library called Capop. It generates a dll called CapopWrap.dll. CapopConsole has CapopWrap as dependency.
CapopWrap has three extra .lib dependencies, namely
capoplib.lib, libpredicates.lib, jsoncpp.lib
in Release mode and
capoplib.lib, libpredicates_d.lib, jsoncppd.lib
in Debug mode.
The first two of each row are from a certain project, special for me, the last one is from the well known jsoncpp project. All three libs are built with Visual Studio 2022 with the new CMake mode (no 'solutions').
Now the point is: Compiling and linking CapopWrap produces both for release and debug mode respectively a result dll, in both cases called CapopWrap.dll.
But: CapopWrap.dll from debug mode has a dependency on jsoncppd.dll whereas CapopWrap.dll from release mode has no explicit jsoncpp related dependency whatsoever (as shown with dumpbin, for example).
By symmetry one might expect that CapopWrap.dll (Release) would incur a dependency on jsoncpp.dll but this is not the case.
I would really be happy, if someone could help me find an explanation for this - my own attempts so far where fruitless.
Addendum: I do not give concrete excerpts from my .csproj and cmake files at first, because they are a bit lengthy and maybe an answer is possible without them. If not, please tell me, what you want to see concretely from my configuration files (or filesystem contents), I will edit it in then.
So I'm a lucky boy, I've been tasked with upgrading the development environment but not the code of a monster classic ASP product. It has been developed over several years and contains huge amounts of superfluous code in.
In order to modernise the development environment I'm targeting the IDE and moving away from FrontPage (yes, I know!); I've created an empty .Net project in VS2015 Community edition, manually added the legacy classic ASP code.
The advantage is by using VSnn it can be linked into TFS seamlessly and allow proper SDLC process to be enforced.
The problem is, I cannot attach a process in order to debug because the legacy code does not compile when I Build -> Build Solution. As I understand it the solution must build in order for the break points to be enabled?
There are 4 error types repeated hundreds of times during build;
Statement cannot appear outside a method body
Identifier expected
Declaration expected
End If must be preceded by a matching If
My questions are, how can I debug this beast if it will not compile?
Is it possible to ignore these warnings for a successful compile?
Is it possible to add break points and hit them in VS2015 for script only debugging?
And yes, I would burn this beast to the ground and use .Net but its not an option.
Something doesn't add up here. Classic ASP files aren't compiled, they are evaluated at runtime. I created a test project with both a WebForms page and Classic ASP page. Both worked by default. I attempted to reproduce your scenario by removing an opening if block but didn't receive any compile errors or warnings.
I am using VS2015 but would suspect to see the same since at least VS2012 if not early versions.
An mixed-mode C++ application is built using VS2012, it references the managed DLL Noesis.Javascript.dll (which I believe was built with VS2010) which in turn links at runtime with msvcr100.dll.
I have observed a crash which seems to show the code within the Noesis.Javascript.dll calling library functions from VS2012's msvcr110.dll.
Is it possible to run a single process using two different versions of the C++ runtime libraries or is what happening here the likely cause of the problem? What is the alternative?
As mentioned for instance in this answer, it is practically impossible to combine these binaries. The crash is probably caused by the incompatiblity.
You could try the following: Project Properties -> General -> Platform Toolset: Visual Studio 2010 (v100).
It is possible to use both runtime DLLs in the same process, but to do so safely requires great care to ensure that no objects from one are used in the other.
I know there are other questions regarding this subject, and I've looked at this question, but I'd like to see a little bit more discussion and information on both sides of this - is it a better practice to add a project to a solution and reference the project, or to add a reference to the .dll?
It's not much of a choice. If you have a solution with both projects then use a project reference. If your solution doesn't have the project then you have to use an assembly reference.
So the real question should probably be: do I create a solution with both projects? Yes, as long as the project is still in the debug stage and liable to require bug fixes.
If you only have the dll then you're stuck with a dll reference (obviously).
If you have the source then it's usually better to use a project reference. There might be cases where you have a utility library that's never going to change, but if there's the slightest chance of you needing a bug fix then having a project reference is going to make debugging a lot easier.
Summary - Project Reference by Project vs by DLL
Reference by project
code is visible
finds all references e.g. on a class (because code is visible)
better for testing (over all)
better for code redesign (impact)
Reference by DLL
code is hidden
separation between e.g. framework and project (for deliver of framework)
quicker compilation (because DLL is already compiled)
Well, project references are helpful when you are building and testing in both debug and release mode. If you directly add a DLL then you are locked into whatever that particular DLL was built as. The project reference allows this to be a build time decision.
Relative to your project architecture, you should always stick to projects within your problem domain. You should be using the GAC, if that is applicable to your environment.
A new project is coming up that will require interaction between Java and C++. It's been decided that the project will be built via Maven2.
Unfortunately I don't know anything about Maven and the Java guys don't know anything about C++.
They have their build chain all set up with various reports being emitted for each part related to CheckStyle, Findbugs, Corbortura(?) etc. and they want the same to be done with the C++ side.
Currently we have 4 apps that need building: 2 services, a tray app and a simple dialog based application. I've been told I need to have a pom for each and configure each to output to a target directory, have the tool chain produce the reports - the most particular being the code coverage which the client wants 100%.
I have sourced the tools - Bullseye and QA-C++ and requested eval copies - but I am dismayed to find there is very little information on C++ & Maven, and what little there is seems to be horror stories.
Does anyone on SO have a good story about it (or have link to blog post)?
Is there a simple explanation anywhere for configuring a Visual Studio solution (preferably C++) to be Mavenized?
I am expecting pain but I am getting increasingly wary of this venture - but unfortunately the project manager is Java side and seems hell-bent on Mavenizing it.
See the following stack over flow on the topic.
Using Maven for C/C++ projects
Hope it helps