***Disclaimer: This information applies to Visual Studio 2010 Beta 1 only.***
Another new feature of the new version of the DSL toolkit is the ability to locks certain operations in a DSL. The idea is that we can define locking policies for a DSL and those policies are executed at runtime to constraint specific operations such as Add/Delete/Update etc.
These locking policies can be defined at three different levels , Store, Partition and ModelElement respectively.
Defining our own locking policies
It is really simple to create our own policy class, we just need to create a class that inherits from ILockingPolicy.
Then we need to define the locks that we are going to return, and for that we have three levels of granularity:
- Store
- Partition
- ModelElement
Locks are transitive following the “Store –> Partition –> ModelElement” object hierarchy.
That means that if we set locks at the Store level, those locks also apply to the Partition and the ModelElement levels.
The lock types are:
public class MyLockingPolicy : ILockingPolicy
{
public Locks RefineLocks(ModelElement element, Locks proposedLocks)
{
return proposedLocks;
}
public Locks RefineLocks(Partition partition, Locks proposedLocks)
{
return proposedLocks;
}
public Locks RefineLocks(Store store, Locks proposedLocks)
{
// TODO: return corresponding locks and they will also apply to Partition and ModelElement
}
}
Injecting our own ILockingPolicy
The Store class constructor sets the locking policy by querying for a ILockingPolicy service. That means that one possible way to inject our own locking policy is to override the GetService method and return our policy class:
internal partial class MyDocData
{
private ILockingPolicy myLockingPolicy;
public override object GetService(Type serviceType)
{
if (serviceType == typeof(SLockingPolicy) || serviceType == typeof(ILockingPolicy))
{
if (myLockingPolicy == null)
{
myLockingPolicy = new MyLockingPolicy();
}
return myLockingPolicy;
}
return base.GetService(serviceType);
}
}
At runtime the DSL infrastructure will query for existing locks using a set of extension methods located in the new ImmutabilityExtensionMethods class and constraint or not an operation accordingly.
The hardware model sample
I published a sample that shows how to lock a DSL.
The scenario is that there are two personas:
- Developer: He uses the VS full IDE to author a hardware model.
- Architect: He uses an Isolated shell to review the model and cannot do any modifications to it.
The locks are being set by detecting the shell SKU.
Pablo
***Disclaimer: This information applies to Visual Studio 2010 Beta 1 only.***
Creating a custom instance/hive for Visual Studio is easier than ever. In this post I will show the details to create a fictitious “pga” instance and configure our VSX development environment to point to it.
This can be useful in some testing scenarios or when we just don’t want to reset the experimental instance to test something.
Creating the pga instance
To create a new instance we use the CreateExpInstance tool:
%VSSDK_Installdir%\VisualStudioIntegration\Tools\Bin\CreateExpInstance.exe /Reset /VSInstance=10.0 /RootSuffix=pga
Once we do that the following directory is created:
%LocalAppData%\Microsoft\VisualStudio\10.0pga\Extensions\
And all existing extensions in the main hive are copied to:
%LocalAppData%\Microsoft\VisualStudio\10.0pga\Extensions\Extensions-10.0
Redirecting the VS SDK msbuild target to the pga instance
Every time that we compile a VSPackage project the Microsoft.VsSDK.targets msbuild target is executed doing all the necessary steps to deploy our extension.
But the default behavior is to deploy the extension under the experimental instance. To override that behavior we need to include the following property in the VSPackage csproj file:
<PropertyGroup>
<VSSDKTargetPlatformRegRootSuffix Condition="'$(VSSDKTargetPlatformRegRootSuffix)' == ''">pga</VSSDKTargetPlatformRegRootSuffix>
</PropertyGroup>
Executing VS pointing to the pga instance
To point Visual Studio to a particular instance we just use the /rootSuffix switch:
%VS_Installdir%\devenv.exe /rootSuffix pga
Or we can just enable the F5 experience from the Debug tab in the project properties:
Pablo
