I am at a new company and they use 2012 Dev Studio express. I would like to use CodeBlocks as the limitations on Express are frustrating.
Assuming I use the MS compiler does CodeBlocks corrupt anything in the Dev studio project structure? Other developers will be working on the same code (via GIT) so I need to make sure that there are no side effects which might effect them.
As far as I am aware there should be no major side effects, maybe a IDE specifics if you're not careful. My group has used Dev (and Visual) Studio Express and CodeBlocks on the same project and it was perfectly fine.
So I doubt there will be any corruption.
Related
If I'm in my WSL2 Ubuntu filesystem I can simply navigate to a javascript/nodejs folder and type code . to open that project folder and thanks to VS Code's Remote extensions, I'm essentially remoting into the Linux environment and ready to code.
Now Visual Studio 2022 has been released, I was wondering if it too supports the same level of cross-platform IDE capability as VS Code?
How, for instance, when in my WSL2 Ubuntu project in Windows Terminal, can I open my javascript/nodejs project in the Linux filesystem using VS2022, or is this not supported because VS Code is the only cross-platform IDE that can do this?
So its not really possible to do how your thinking. The problem here is that you your not understanding the difference between a "Code Editor", and an "Integrated Development Environment (IDE)", which is totally understandable, as the line that separates the two has become blurred in recent years, and also a topic of debate. There was a far more explicit distinction between the 2 10-15 years ago, however, Microsoft has done a good job at separating the two, where JetBrains will release a piece of software that can be used as an IDE, but is more often than not, used as an editor, but will still call it an IDE, even though its not an IDE in a pure sense.
How is all this related to your question?
When you open your Node.js project in VSCode via the code . command, you are opening it in an editor that implements Intelli-code, as well as a wealth of other tools, but essentially, the editor, and all the tools extract the names & file extensions of your documents, parse them (usually turning much of the info into an AST, where many extensions will make use of that info to offer the various tooling capabilities/features. The point is at the end of the day, the editor just parses all of your code, gives you info, and you make any changes as needed to your code. And again, this is what your doing with code .
With Visual Studio 2022, you can't open a project with it, unless its a project type the IDE supports, and enables the IDE, to embed its-self into your project. This includes things like built in environment, built in cache, built in build system, the files needed to bootstrap its-self. With an IDE, the IDE is part of the project.
So then why does Visual Stdio 2022 work with Node?
It works with node, to create Node.js applications within a windows environment, and it offers the ability to access different Windows SDK features via Node. These are things you could never do using server-side Linux builds with Node. When you build a Cpp application for windows, you package the entire thing in a .sin file, I haven't built a windows app in node, but I know that Node also uses the .sin file build system, which requires Visual Studio & Windows SDK to do, and parts of Visual Studio/Windows to be embedded into the project, for the project to be able to work in a Windows OS, and take advantage of MS Windows features.
Long story short, V.S. Code is the right tool for what your doing, why would Microsoft invest in two identical tools any way? If you ever want to build something for Windows, or for MS mobile device using Node, you will probably want to change your environment, to VS2022.
Usually we're in a microsoft stack development but for the project purposes we need to develop in node.js in visual studio 2017.
There are some things we don't understand at all but are quite annoying.
We've installed node.js tools for Visual Studio 2017 but intellisense work for some things and doesn't for others.
2 main problems we're facing:
For example, for some node modules (router, express, etc...) intellisense works fine. For others (mongorito, for examlple, but its not mongorito specific, there are many others also) we don't get any intellisense nor we can navigate through its definitions ('go to definition').
For any file we open we get alot of TSxxx error messages. something like this:
Don't know if its important but with the same setup we had our team members to work on angular 2/4 projects (that use node modules, of course) and everything worked fine.
So, if anyone has a piece of advice we would highly appreciate it. And please explain it like for a complete idiots.
PS.
Don't know if its important, but i must say that solution builds, all tests are good and all runs as it should. Its IDE problem.
So, for everyone having the problem i'll post the solution here.
Problem was in typescript version. Now, that comes with a few details.
In Visual studio pre 15.2 you can't have typescript versions switching. So, i first updated VS to 15.2.
After that, i've installed Typescript SDK with latest typescript (2.4.1. i think at the moment).
Then go to Tools > Options > TextEditor > Javascript/Typescript > Intellisense > Here choose typescript version from the drop down.
[I'll leave answer unaccepted for a bit for the case someone comes with a better solution]
I am currently experiencing a strange issue with Node.js within Visual Studio.
I'm currently working on multiple projects (containing many typescript files - i've read elsewhere this could possibly have something to do with my problem) in Visual Studio 2015 (Version 4.7.02053). I have node.js (v 6.10.0) installed on my dev machine also. Currently we are using the built in TypeScript compiler within visual studio (previously using grunt for ts compilation, now just for sass).
I've also configured visual studio to use the current version of node I have installed (please see screenshot below):
Custom Path to node.js installation
My issue is this, whenever I open one of my projects, multiple, I mean a lot, I mean like between 50-100 node.exe processes spin up, please see the image below!
Lot's of node processes, seems to be update-notifier\check.js???
This is eating away at my CPU and rendering my machine barely usable, especially when i have three or four separate projects open at the same time.
I've attempted to google a fix for this but haven't come up with anything that has worked thus far, so, any help you could possibly give me is greatly appreciated.
Thanks in advance,
Paul
This seems to have to do with the update-notifier package.
I am using visual studio 2015 on windows to develop a c++ application for a linux machine using the linux project template. So far I have built the libraries I need on the remote machine, then transferred those libraries to my windows machine.
From there I have included them in my project as normal (in the project properties), but there are still some errors when I am building the project, as far as I can tell they are link errors. I am fairly certain I have included all the necessary files and linked everything correctly within the IDE.
This is purely for fun and a learning experience for me, so please forgive me if I am way off base here. I have read about makefiles but am still new to linux development and was just wondering if anyone has any experience with this.
If this cant be done remotely from within the visual studio IDE I would love to hear suggestions.
EDIT: It seems I was mistaken about what it was exactly that I am trying to do, sorry guys.
You cannot link libraries on Windows with MSVC compiler that you compiled on your remote Linux machine with a different compiler. You will need to recompile them.
We're planning moving from Visual Studio 2005 to Visual Studio 2012 (Visual-C++-11).
(We would very much like to skip 2010 if we can help it, since the newer version is already there and offers a better C++ experience.)
But we've hit a little roadblock:
Our build servers still run Windows 2003r2 (all inside dedicated virtual machines), and due to messy tool support/issues, we're in no position to upgrade the build servers to a newer OS.
Developers mostly have switched to Windows7 by now, so moving the remaining Windows XP developer boxes shouldn't pose a problem.
Since VS2012 only runs on Win7 we are wondering whether we can leverage it's tools (C++ compiler, C#) and still do a full equivalent build on the W2k3 build server - after all, we don't really need a VS GUI there, just build C++ and C# projects from VS2012.
What are our options?
Will the SDK (7.1? 8?) compilers + msbuild command line get me anywhere?
In Project Property Pages, there an option "Platform Toolset" that allow you to choose compatibility of your project. So, you can work in VS2012, but built it with "VS2008 compiler"
Here is what we do:
Use CMake
CMake allows you to create build systems for your operating system. Thus we are able to use the same code within VS2005, VS2010 and Eclipse, XCode etc.
You could do something similar: Install VS2005 on your old machines and let CMake create the projects for you from the sources. On your newer machines you can use CMake to generate VS2012 Solutions (I don't know if they have 2012 support yet, because we don't use 2012 yet too).
A big pro here is: If you plan to migrate to any other IDE or even Linux you just can re-run CMake and get your source code within these environment easily compilable.
A big con: You have to start reading about CMake and create CMakeLists.txt for all your projects (might be a lot of work depending on the amount of projects, amount of source code files within each project, specific compiler options, linker options etc.)
Our build servers still run Windows 2003r2 (all inside dedicated
virtual machines), and due to messy tool support/issues, we're in no
position to upgrade the build servers to a newer OS.
Well. Not much came out of this question. We recently re-evaluated this issue, and I see two options (I haven't tried any yet):
Just do a full VS installation on a supported OS (Win7), zip up the whole VS+WinSDK directories (as well as the neccesary runtme DLLs that live somewhere under %WINDR%), and try if you can get that thing working on an XP based OS. Might work. Not a great idea if you ask me.
Split up the build process to distribute the build across several OS, so that we can work with tools that are only supported on one of them. -- This actually sounds more complicated than it'll be. We already run our build spread over several Jenkins jobs, so I should be able to get that to work. (And all build nodes are already VMs anyway, so adding more VMs isn't that much of an issue.)