MPS enables me to build standalone IDEs (see https://confluence.jetbrains.com/display/MPSD34/Building+standalone+IDEs+for+your+languages), however Windows builds would definitely need a JDK/JRE. The users get confused with installing Java, etc.
Are there "pre-built" JDKs compatible with MPS (IntelliJ platform)?
What are the approaches to update the bundled Java? IntelliJ platform does have an updater, however does it support updating the Java runtime? The updater is Java-based, so I wonder how does it update Java runtime when using the same runtime.
Can something like JetBrains Toolbox to manage updates of the "third-party" MPS-based IDEs?
PS. I'm using for MPS 2017.3, mbeddr if that matters.
I'm not exactly sure if the are publicly available but you can check JBs teamcity at teamcity.jetbrain.com where all their open source stuff is available.
The updater for intellij performs incremental updates to the jar files. It is not open source and it usually only used to do small updates. If there is a major update like new platform with a bunch of API updates it is not used and the user has to download complete new installer. In MPS the incremental updater is not used. So each MPS updates is complete new IDE to be downloaded by the end user (or JB toolbox).
I don't know how the JB toolbox works but you can use MPS/IntelliJs normal update mechanics to notify users about updates to your custom IDE. In the branding you create for your custom IDE there is field where you can point it to a update location. Which then serves a xml file with the update information. The format is pretty straight forward. Here is a sample. Your IDE will check on start up or at least once a day if an update is available.
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.
I'm slowly migrating projects to VS2017 from VS2015. We have distributed team and until all is verified (there are issues with e.g. Reporting Services, SSIS, etc as there is not fully finished tooling - SSDT) I need the projects could work in VS2015 without changes.
C# projects in VS2017 use latest C# version by default in project settings (in my case it is C# 7.1) and ReSharper started to offer refactoring to these new features. However, I need to resist the temptation and wait until all is migrated (while I still need to be able to write and review code). I need to specify the version of C# to be 6.0. I can do it on per project basis but I would like to avoid this as I would have to go through each project, modify it and push it to source control and when the migration is done then I would have to switch it back.
Is there a way in R# to globally set the C# version in options (haven't found such a setting but maybe there's some hidden option?)
(VS2017 - 15.4.5, ReSharper 2017.2.2)
EDIT
For Typescript there is possibility to specify language level - either auto-detection or exact version. So for C# it could be similar - auto-detection from project settings or exact version. It would allow code review for specific language version without modification of the projects.
I'm adding here also the link to R# support page as I asked there too
Add the following string to solution settings file ({Solution name}.sln.DotSettings file in the solution's root folder)
<s:String x:Key="/Default/CodeInspection/CSharpLanguageProject/LanguageLevel/#EntryValue">CSharp60</s:String>
I really miss the newer functions of a modern Eclipse implementation. Things like cool plugins such as Checkstyle, auto-javadoc, ease of JUnit testing.
I always did this whilst developing Notes Java Agents, and it was a great time saver.
I'm trying to do this with my new XPages project but I'm stumbling on how to include diverse OSGI libraries.
Can anyone help?
The quickest way to set up an Eclipse environment for XPages development is the XPages SDK. That should point to your Notes/Domino installations and create the Target Platform stuff for you. If you have additional libraries, you can either install them into Eclipse via the Help -> Install New Software option or add them to the Target Platform in Preferences -> Plug-in Development -> Target Platform.
There's a huge caveat, though: this sort of XPages development refers to library development specifically, not writing XPages applications. There isn't really currently a good way to do actual-XPages dev in Eclipse without losing tooling.
In addition to Jesse's answer: a colleague uses Eclipse only to develop in our XPages stuff - for the Java part only. We all use a local on-disk-version of the project that can be imported into Eclipse workspace. You then can use the editors and benefits of current Eclipse versions. Caveat also: you always have to refresh/sync the sources from your on-disk-project in DDE to test. Regarding JUnit tests: we also use them and doing even automated build-tests on a Jenskins server with that method
I am developing an InstallShield InstallScript project (not MSI) and currently working on the "updatemode" behaviour of the setup.exe program.
I would like to know if it is possible to ignore the update of one specific feature and still update the other ones.
The problem is that the program needs to determine whether the feature should be updated during the execution, which means the feature has to be embedded in the update program.
I've already tried to use the InstallScript function FeatureSetItem, but when I set my feature to false, the feature is not ignored, but uninstalled by my update program.
Any idea would be helpful.
Not sure what it is that you don't want to be updated or why, but if it's just files then set the components for the feature to "overwrite by date" or "overwrite by version".
In InstallShield, go to "Releases". Create a new "Release" and then go through the Release Wizard.
One of the windows in the release wizard allows you to check/uncheck the features for that release. Simply uncheck the features that you do not want to update. This way, those features will not be included when you build that particular release configuration. They will still be included if you build using the original release configuration.
I am not a full time programmer, but have to do a little bit to build tools to support my job. I have finished writing my application which I now need to deploy.
I do not want to use "ClickOnce" as I need to alter files in the 'local' folder at configuration time. My understanding is that if I use the Publish option under the Build menu, then I am using "ClickOnce".
My research has led me to believe that "You do this by adding one or more deployment projects to your solution". MSDN then states, that to acheive this I need to select 'Add Project' and "In the resulting Add New Project dialog box, select the Setup and Deployment Projects folder."
The problem is, I do not have such an option ?!
Can someone shed some light on why this would be the case, and how I go about fixing it. I have spent half a day googling and cannot come up with a way forward?
Details of Project and System are as follows:
Environment: Visual Studio 2012 Express for Windows Desktop.
Current Project: Windows Form Application.
Op Sys: Windows 7 Professional.
Correct though its advice may be, that is an old tutorial that you're reading. It is probably referring to Visual Studio 2010.
That option has been removed in VS 2012. You will need to use an alternative tool to build your installer. For example:
WiX
Inno Setup
InstallShield
…etc.
I strongly suggest looking at Wix#. See http://www.codeproject.com/Articles/31407/Wix-WixSharp-managed-interface-for-WiX. If you are doing your coding in C#, Wix# this would probably be the most simple and comfortable skill set to add, and it is free and would directly integrate into the Visual Studio environment you are using.
More info at the CodePlex home page for Wix#: http://wixsharp.codeplex.com/
For C# developers needing to create a Windows Installer MSI to deploy their app, Wix# is perhaps the best replacement for the "Packaging and Deployment" project type that Microsoft removed from Visual Studio starting with VS2012. Wix is a C# front end for the WiX (Windows Installer Xml) Toolset. Using Wix# allows building a complete Windows Installer MSI in the C# language.
Wix# is useful for a broad range of installation/deployment scenarios, and lends itself reasonably well to Continuous Integration scenarios. There are Wix# examples for deploying Windows desktop applications, for installing Windows Services, and installing ASP.NET websites, and many more types of installations.
The question mentioned a need to install applications on Windows 7. Wix# supports this environment, and handles typical installer requirements, and the Wix# installer code for simple projects is indeed simple. For application installs that are more complex, and require advanced features, Wix# can tap into the power of the full WiX Toolset when needed. For example, when installing a .NET application, a typical requirement would be to install the application exe and dll files, and tailor some .NET configuration files and/or registry entries on the target system.
Below is an example of the C# code for a simple Wix# installer that installs an application on a target system, and modifies some configuration files. This example assumes that you have written a utility named "TailorMyConfig.exe", e.g., a simple C# program that uses ConfigurationManager.AppSettings routines, and you are deploying this exe along with your app.
using System;
using System.Windows.Forms;
using System.Diagnostics;
using Microsoft.Deployment.WindowsInstaller;
using WixSharp;
class Script
{
static public void Main(string[] args)
{
var project = new Project("MyProduct",
new Dir(#"%ProgramFiles%\My Company\My Product",
new File(#"Files\Bin\MyApp.exe"),
new File(#"Files\Bin\TailorMyConfig.exe")),
new ManagedAction("UpdateConfigFile"));
project.Id = new Guid("6f330b47-2577-43ad-9095-1861ba25889b");
Compiler.BuildMsi(project);
}
}
public class MyCustomAction
{
[CustomAction]
public static ActionResult UpdateConfigFile(Session session)
{
if (DialogResult.Yes == MessageBox.Show("Config file update ready to run.\n Update config file(s) now?",
"Config Tailoring Utility",
MessageBoxButtons.YesNo))
{
Process.Start("TailorMyConfig.exe", "Run utility to tailor config file to current system");
}
return ActionResult.Success;
}
}
Note that there are "better" ways to modify a config file using WiX XML features. For simplicity, the example above assumed a custom-written C# exe utility for modifying config files. I would suggest using WiX XML capabilities for doing this instead. You can incorporate nearly any WiX XML capabilities directly into your Wix# setup using the Wix# technique of "XML injection".
Remember, Wix# is simply a C# front end that emits WiX XML syntax. After Wix# has emitted the WiX XML (wxs file), that wxs file can easily be post-processed to insert additional WiX XML features. Then the resulting wxs file gets compiled by the WiX Toolset into an MSI.
For an example of using XML Injection to incorporate WiX XML features into a Wix# (C#)installation, look here In Wix#, how to avoid creating a physical folder on the target system, when deploying only registry entries?
In that question, see my answer that uses the technique of hooking up a delegate to the "WixSourceGenerated" event.
You could then use this XML injection approach to insert some WiX XML into your installer that would accomplish the config file editing. An example of some typical WiX XML to modify config files is here:
How to modify .NET config files during installation?
Another typical requirement of an installer would be to add or modify Windows Registry entries on a target system. Wix# provides direct support for that using the "RegValue" class. The advantage there is when using Wix# you also get a full "uninstall" capability for free, including uninstalling/reverting registry entries to the pre-install state. This is a natural result of Wix# being built on top of the WiX Toolset and Windows Installer technology. An example of a registry-only Wix# installer is here: In Wix#, how to avoid creating a physical folder on the target system, when deploying only registry entries?
The Wix# approach has been very useful in my environment, and it allows use of the familiar C# skillset without having to jump headfirst into the full complexity of the WiX XML installer technology.