Constructor of external type 'XXXX' can cause side effects

Question

Hi!

I use a C# DLL in my Axum Project and when I compile the two I get the compiler Message
"Constructor of external type 'SimHelper.SimHelp' can cause side effects"   (SimHelper is obviously my DLL Project)

This here is the Axum Part

        public MainAgent()
        {
                       
           
            SimHelp test = new SimHelp();              

            Console.ReadLine();
            PrimaryChannel::Done <-- Signal.Value;
        }


Why does that happen? How can I fix this?

EDIT: I tried to compile the WebFetcher Example and have the Same problem.... ?!
Axum 0.2 VS2008


Thanks!
alexl

Answer 1

Hi Alexl,

The issue with WebFetcher is actually a known issue.

Axum is isolated and safe by default, so if it knows nothing about the constructor of your class, it assumes that it has side-effects and throws an error when you use it from a reader agent. Essentially there are three ways to fix this if your constructor truly does not have side-effects.

1.  Compile using the Axum C# compiler and mark the class as isolated.  This is touched on in the programmer's guide.  If your class doesn't have any side-effects at all, you can use the isolated modifier and compile the file as a .qcs file in an Axum project.

2.  Create a contract assembly that tags the class as isolated.  If you can't recompile or don't want to compile using the Axum project system, you can create a contracts assembly.  This method is also outlined in the programmer's guide as well as the link above.

3.  Use the unsafe { } construct.  This is the least desirable but quickest method.  In Axum you can wrap the instantation of your SimHelp object with unsafe { } which tells the compiler to ignore safety within those brackets.

Hope that helps!

Josh

Answer 2

Thanks Josh! And sorry for my sluggish research, but I missed these parts in the Language Ref.

What I want to do in my app is to access SQL Server and later SSAS, so I don't have access to the assemblies.

I understand the concept of the contract assemblies but I can't make it work. Did you already publish the fixed version of the WebFetcher Sample?
Or something else where I can see a 'working contract assembly'?!

This would be a great help!

Thanks
AlexL

Answer 3

Hi AlexL,

We never published a fixed version of the WebFetcher example.

I created this contract assembly and it seems to work:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Diagnostics.Effects;
using System.Net;
using System.IO;

[assembly: System.Diagnostics.Effects.ContractAssembly]

namespace Contracts
{
    namespace System.Net
    {
        [Strict]
        public abstract class WebRequest
        {
            public static WebRequest Create(string url) { throw new NotImplementedException(); }
            public static WebRequest Create(Uri uri) { throw new NotImplementedException(); }
            public abstract WebResponse GetResponse();
            
        }

        [Strict]
        public abstract class WebResponse
        {
            public abstract Stream GetResponseStream();
        }
    }
}

Note:  This has to be built as a 3.5 assembly.  Each Axum project that uses these methods must reference the contract DLL.

Josh

Answer 4

What assembly contains the "Strict" attribute and System.Diagnostics.Effects???? So I can make a contract assembly

Answer 5

I added

tsecontracts
tsecorelib
Microsoft.Axum.LanguageService
Microsoft.Axum.Compiler

to the c# project.
Don't know if I need them all, but it works.

Answer 6

I used the object brower and found them in the 2nd assembly "tsecorelib" thank you very much!

Answer 7

I added

tsecontracts
tsecorelib
Microsoft.Axum.LanguageService
Microsoft.Axum.Compiler

to the c# project.
Don't know if I need them all, but it works.

Yes, this works for me, too. Any way, very happy that it was solved finally. Thanks for your help.

Answer 8

This happens because the compiler thinks your class constructor is a source of potential non-isolation. Axum tries to enforce parallel safety through isolating state from being accessed from different threads uncontrollably. Since the compiler doesn't know that your constructor doesn't access static variables, for example, it treats it as a potential problem.

The way to get around this is to tell the compiler more about the external code through isolation attributes. How to do this is discussed in detail in Appendix C of the Axum Programmer's Guide, "Understanding Side-Effects." If your constructor isn't doing something unsafe, you should be fine. If it is, you have two choices: a) lie about it and have the Axum compiler think it's safe when it isn't, or b) use the 'unsafe { }' code block around the offending code. This highlights code that isn't following the principles of isolation and are generally a red flag that something is about to go wrong.

Hope this helps,

Niklas

Answer 9

I just noticed that I replied to the original post rather than the latest post of the thread... Kinda stupid..

Niklas