The problem is that instead of finding the actual GameObject in the scene, which has this solar script attached to it, and activating the solarshield on that GameObject, you are creating a new instance of the Solar class (which probably does not have anything assigned to the solarshield variable) and activating that - this gives a NullReferenceException.
This is a very common misconception. You have to realize that the Solar class is just a code. If you want to use it in your game, you have to create an instance of it. You are creating this instance by adding it as a component to a GameObject.
When you say, you want to access another script, you actually want to access the instance - which is on that specific GameObject. For example, if you have two GameObjects with the Solar script attached to them, you will have an instance 01, and an instance 02 of that script. If you want to change the first instance, obviously you can not access the second one - that makes no sense. That’s why you need references.
Instead of creating a new instance (which is basically a blank Solar script), you should search for the GameObject (which has the Solar script on it, that you want to change), get the Solar script component, and after that you can access that variables of that instance.
For example, if you have a GameObject in the scene (lets name it ‘ObjectA’), you can use this line to access the variable from another script:
GameObject.Find("ObjectA").GetComponent<Solar>().solarshield
By this, you can use the solarshield GameObject reference on the Solar script component, which is attached to ObjectA.
If you can understand this, you will have no problem with accessing other instances later. And be careful about static variables, since they will be shared across all instances - which makes this whole concept no longer useful. With static variables you will not be able to change instances separately, which is crucial in order to create diverse objects.