Sep 16, 2019  Excel VBA Missing Reference to Microsoft Scripting Runtime When I am in the VB Editor on a clients computer, and i choose tools references and want to check Microsoft Scripting Runtime. This may because you are encountering with another problem, or something in your script you didn't mentioned. For example, I tested the following sample code uses Microsoft Scripting Runtime (scrrun.dll), and it turns out to be fine before and after the update. I believe that anti-virus programs and in other ways also you can disable the Scripting.FilySystemObject on a PC. I have a few computers with different OS such as XP Home, Win98 and a XP Pro that a program I have that uses the Microsoft Scripting Runtime reference and the FileSystemObject where the FSO does not work I think is the problem.

C# and .NET, the technologies underlying Unity scripting, have continued to receive updates since Microsoft originally released them in 2002. But Unity developers may not be aware of the steady stream of new features added to the C# language and .NET Framework. That's because before Unity 2017.1, Unity has been using a .NET 3.5 equivalent scripting runtime, missing years of updates.

With the release of Unity 2017.1, Unity introduced an experimental version of its scripting runtime upgraded to a .NET 4.6, C# 6 compatible version. In Unity 2018.1, the .NET 4.x equivalent runtime is no longer considered experimental, while the older .NET 3.5 equivalent runtime is now considered to be the legacy version. And with the release of Unity 2018.3, Unity is projecting to make the upgraded scripting runtime the default selection, and to update even further to C# 7. For more information and the latest updates on this roadmap, read Unity's blog post or visit their Experimental Scripting Previews forum. In the meantime, check out the sections below to learn more about the new features available now with the .NET 4.x scripting runtime.

Re: FileSystemObject / Microsoft Scripting Runtime in Excel 2010 VBA Cheers mate. The extension of my files changed to.xlsx, so I only had to adapt this in the code.

Prerequisites

• Unity 2017.1 or above (2018.2 recommended)

Enabling the .NET 4.x scripting runtime in Unity

To enable the .NET 4.x scripting runtime, take the following steps:

1. Open PlayerSettings in the Unity Inspector by selecting Edit > Project Settings > Player.

2. Under the Configuration heading, click the Scripting Runtime Version dropdown and select .NET 4.x Equivalent. You will be prompted to restart Unity.

Choosing between .NET 4.x and .NET Standard 2.0 profiles

Once you've switched to the .NET 4.x equivalent scripting runtime, you can specify the Api Compatibility Level using the dropdown menu in the PlayerSettings (Edit > Project Settings > Player). There are two options:

• .NET Standard 2.0. This profile matches the .NET Standard 2.0 profile published by the .NET Foundation. Unity recommends .NET Standard 2.0 for new projects. It's smaller than .NET 4.x, which is advantageous for size-constrained platforms. Additionally, Unity has committed to supporting this profile across all platforms that Unity supports.

• .NET 4.x. This profile provides access to the latest .NET 4 API. It includes all of the code available in the .NET Framework class libraries and supports .NET Standard 2.0 profiles as well. Use the .NET 4.x profile if your project requires part of the API not included in the .NET Standard 2.0 profile. However, some parts of this API may not be supported on all of Unity's platforms.

You can read more about these options in Unity's blog post.

Adding assembly references when using the .NET 4.x Api Compatibility Level

When using the .NET Standard 2.0 setting in the Api Compatibility Level dropdown, all assemblies in the API profile are referenced and usable. However, when using the larger .NET 4.x profile, some of the assemblies that Unity ships with aren't referenced by default. To use these APIs, you must manually add an assembly reference. You can view the assemblies Unity ships with in the MonoBleedingEdge/lib/mono directory of your Unity editor installation:

For example, if you're using the .NET 4.x profile and want to use HttpClient, you must add an assembly reference for System.Net.Http.dll. Without it, the compiler will complain that you're missing an assembly reference:

Visual Studio regenerates .csproj and .sln files for Unity projects each time they're opened. As a result, you cannot add assembly references directly in Visual Studio because they'll be lost upon reopening the project. Instead, a special text file named mcs.rsp must be used:

1. Create a new text file named mcs.rsp in your Unity project's root Assets directory.

2. On the first line in the empty text file, enter: -r:System.Net.Http.dll and then save the file. You can replace 'System.Net.Http.dll' with any included assembly that might be missing a reference.

3. Restart the Unity editor.

Taking advantage of .NET compatibility

In addition to new C# syntax and language features, the .NET 4.x scripting runtime gives Unity users access to a huge library of .NET packages that are incompatible with the legacy .NET 3.5 scripting runtime.

Add packages from NuGet to a Unity project

NuGet is the package manager for .NET. NuGet is integrated into Visual Studio. However, Unity projects require a special process to add NuGet packages. This is because when you open a project in Unity, its Visual Studio project files are regenerated, undoing necessary configurations. To add a package from NuGet to your Unity project do the following:

1. Browse NuGet to locate a compatible package you'd like to add (.NET Standard 2.0 or .NET 4.x). This example will demonstrate adding Json.NET, a popular package for working with JSON, to a .NET Standard 2.0 project.

2. Click the Download button:

3. Locate the downloaded file and change the extension from .nupkg to .zip.

4. Within the zip file, navigate to the lib/netstandard2.0 directory and copy the Newtonsoft.Json.dll file.

5. In your Unity project's root Assets folder, create a new folder named Plugins. Plugins is a special folder name in Unity. See the Unity documentation for more information.

6. Paste the Newtonsoft.Json.dll file into your Unity project's Plugins directory.

7. Create a file named link.xml in your Unity project's Assets directory and add the following XML. This will ensure Unity's bytecode stripping process does not remove necessary data when exporting to an IL2CPP platform. While this step is specific to this library, you may run into problems with other libraries that use Reflection in similar ways. For more information, please see Unity's docs on this topic.

With everything in place, you can now use the Json.NET package.

This is a simple example of using a library which has no dependencies. When NuGet packages rely on other NuGet packages, you would need to download these dependencies manually and add them to the project in the same way.

New syntax and language features

Using the updated scripting runtime gives Unity developers access to C# 6 and a host of new language features and syntax.

Auto-property initializers

In Unity's .NET 3.5 scripting runtime, the auto-property syntax makes it easy to quickly define uninitialized properties, but initialization has to happen elsewhere in your script. Now with the .NET 4.x runtime, it's possible to initialize auto-properties in the same line:

String interpolation

With the older .NET 3.5 runtime, string concatenation required awkward syntax. Now with the .NET 4.x runtime, the $ string interpolation feature allows expressions to be inserted into strings in a more direct and readable syntax:

Expression-bodied members

With the newer C# syntax available in the .NET 4.x runtime, lambda expressions can replace the body of functions to make them more succinct:

You can also use expression-bodied members in read-only properties:

Task-based Asynchronous Pattern (TAP)

Asynchronous programming allows time consuming operations to take place without causing your application to become unresponsive. This functionality also allows your code to wait for time consuming operations to finish before continuing with code that depends on the results of these operations. For example, you could wait for a file to load or a network operation to complete.

In Unity, asynchronous programming is typically accomplished with coroutines. However, since C# 5, the preferred method of asynchronous programming in .NET development has been the Task-based Asynchronous Pattern (TAP) using the async and await keywords with System.Threading.Task. In summary, in an async function you can await a task's completion without blocking the rest of your application from updating:

TAP is a complex subject, with Unity-specific nuances developers should consider. As a result, TAP isn't a universal replacement for coroutines in Unity; however, it is another tool to leverage. The scope of this feature is beyond this article, but some general best practices and tips are provided below.

Getting started reference for TAP with Unity

These tips can help you get started with TAP in Unity:

• Asynchronous functions intended to be awaited should have the return type Task or Task<TResult>.
• Asynchronous functions that return a task should have the suffix 'Async' appended to their names. The 'Async' suffix helps indicate that a function should always be awaited.
• Only use the async void return type for functions that fire off async functions from traditional synchronous code. Such functions cannot themselves be awaited and shouldn't have the 'Async' suffix in their names.
• Unity uses the UnitySynchronizationContext to ensure async functions run on the main thread by default. The Unity API isn't accessible outside of the main thread.
• It's possible to run tasks on background threads with methods like Task.Run and Task.ConfigureAwait(false). This technique is useful for offloading expensive operations from the main thread to enhance performance. However, using background threads can lead to problems that are difficult to debug, such as race conditions.
• The Unity API isn't accessible outside the main thread.
• Tasks that use threads aren't supported on Unity WebGL builds.

Differences between coroutines and TAP

There are some important differences between coroutines and TAP / async-await:

• Coroutines cannot return values, but Task<TResult> can.
• You cannot put a yield in a try-catch statement, making error handling difficult with coroutines. However, try-catch works with TAP.
• Unity's coroutine feature isn't available in classes that don't derive from MonoBehaviour. TAP is great for asynchronous programming in such classes.
• At this point, Unity doesn't suggest TAP as a wholesale replacement of coroutines. Profiling is the only way to know the specific results of one approach versus the other for any given project.

Note

As of Unity 2018.2, debugging async methods with break points isn't fully supported; however, this functionality is expected in Unity 2018.3.

nameof operator

The nameof operator gets the string name of a variable, type, or member. Some cases where nameof comes in handy are logging errors, and getting the string name of an enum:

Caller info attributes

Caller info attributes provide information about the caller of a method. You must provide a default value for each parameter you want to use with a Caller Info attribute:

Using static

Using static allows you to use static functions without typing its class name. With using static, you can save space and time if you need to use several static functions from the same class:

IL2CPP Considerations

When exporting your game to platforms like iOS, Unity will use its IL2CPP engine to 'transpile' IL to C++ code which is then compiled using the native compiler of the target platform. In this scenario, there are several .NET features which are not supported, such as parts of Reflection, and usage of the dynamic keyword. While you can control using these features in your own code, you may run into problems using 3rd party DLLs and SDKs which were not written with Unity and IL2CPP in mind. For more information on this topic, please see the Scripting Restrictions docs on Unity's site.

Additionally, as mentioned in the Json.NET example above, Unity will attempt to strip out unused code during the IL2CPP export process. While this typically isn't an issue, with libraries that use Reflection, it can accidentally strip out properties or methods that will be called at run time that can't be determined at export time. To fix these issues, add a link.xml file to your project which contains a list of assemblies and namespaces to not run the stripping process against. For full details, please see Unity's docs on bytecode stripping.

.NET 4.x Sample Unity Project

The sample contains examples of several .NET 4.x features. You can download the project or view the source code on GitHub.

Additional resources

When I try to execute my PowerShell script I get this error:

File C:CommonScriptshello.ps1 cannot be loaded because the execution of scripts is disabled on this system. Please see 'get-help about_signing' for more details.
At line:1 char:13
+ .hello.ps1 <<<<
+ CategoryInfo : NotSpecified: (:) [], PSSecurityException
+ FullyQualifiedErrorId : RuntimeException

11 Answers

1. Start Windows PowerShell with the 'Run as Administrator' option. Only members of the Administrators group on the computer can change the execution policy.

2. Enable running unsigned scripts by entering:

This will allow running unsigned scripts that you write on your local computer and signedscripts from Internet.

See also Running Scripts at Microsoft TechNet Library.

The Default Execution Policy is set to restricted, you can see it by typing:

You should type the following to make it go to unrestricted mode:

Hope this helps

On my machine that I use to dev scripts, I will use -unrestricted as above. When deploying my scripts however, to an end user machine, I will just call powershell with the -executionpolicy switch:

We can get the status of current ExecutionPolicy by the command below:

By default it is Restricted. To allow the execution of PowerShell Scripts we need to set this ExecutionPolicy either as Bypass or Unrestricted.

We can set the policy for Current User as Bypass or Unrestricted by using any of the below PowerShell command:

Unrestricted policy loads all configuration files and runs all scripts. If you run an unsigned script that was downloaded from the Internet, you are prompted for permission before it runs.

Whereas in Bypass policy, nothing is blocked and there are no warnings or prompts during script execution. Bypass ExecutionPolicy is more relaxed than Unrestricted.

Depending on the Windows version and configuration, you may have the following warning, even in Unrestricted mode:

The solution is to use the 'bypass' policy, enabled with the following command:

From the documentation:

Bypass: Nothing is blocked and there are no warnings or prompts.

This is obviously insecure, please understand the risks involved.

A reg key with:
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsPowerShell] 'EnableScripts'=dword:00000001 'ExecutionPolicy'='Bypass'

and:

works indeed too.

Enable Microsoft Scripting Runtime Vba

For some reason the PowerShell cmdlet did not enable local execution globally, just for the local user context. If I tried to start a Powershell script from inside CygWin's bash prompt, for example, which runs under its own user context, it would not run, giving the 'is not digitally signed' error. The answer was to go into the Local Group Policy Editor -> Local Computer Policy -> Administrative Templates -> Windows Components -> Windows PowerShell and double-click on 'Turn on Script Execution'. This then let me change it to 'Enabled' and then execution policy of 'Allow local scripts and remote signed scripts' and have it work globally regardless of user context.

The accepted answer is right, but the policy modification is only available for the currently running instance of the Powershell, meaning once the instance of the Powershell is shut down. The policy will be reset. If a user reopens another instance of Powershell, the default policy will be applied which is Restricted

For me, I need to use the VisualStudio Code console and g++ from cygwin to build things. The console is using Powershell, with the default policy, nothing can be done. One solution is changing the policy everytime the console is fired in VisualStudio Code console, maybe a script of changing the policy.

I am lazy, so another solution is when I run the Powershell in admin mode, similar to what the accepted answer does. but with an extra parameter which changes values in the Registry table. Once it been done. Other instances of Powershell will use the RemoteSigned policy by default.

set-executionpolicy remotesigned -Scope CurrentUser

Setting the policy (correctly) is the best choice but on my managed systems I do not have the ability to change that policy.

For me, the simplest work-around to changing the policy is to open the script in the 'PowerShell ISE', highlight the code (or part of the code) to execute and then click the 'Run Selection' button (or use the F8 shortcut).

This is not the best solution & does little for automating tasks, but it does allow me the use & utility of PowerShell while not running afoul of my IS department.

Excel Enable Microsoft Scripting Runtime

Here's the simplest way. Start the Windows Power Shell in Run as Administrator Mode by Right-Click on it. then type this command:

set-executionpolicy remotesigned

That's all.

The reason that the reg key works, is because it is doing exactly what the PS commands do. The commands write the changes to the reg keys. Commands are much quicker and easier than creating a reg key or digging into the registry.

Microsoft Scripting Runtime Excel

Not the answer you're looking for? Browse other questions tagged powershell or ask your own question.