I have a Dynamics365 DevVM and updated it from 10PU26 to 10PU28 so that i develop on the same platform version as the systems i am developing for. After applying 10pu28 i started my VisualStudio, changed something and tried to save and compile but noticed that BP is broken and so i can't develop further. Visual Studio logs the following but i am not sure what i can do to fix this.
Build started 07/25/2019 06:27.
Build step: Metadata validation started.
Exception occured while performing operation Validate Metadata. Exception details: Path: []:System.ArgumentNullException: Value cannot be null.
Parameter name: source
at System.Linq.Enumerable.Contains[TSource](IEnumerable`1 source, TSource value, IEqualityComparer`1 comparer)
at Microsoft.Dynamics.Framework.Tools.ILGeneratorAgent.CompilationService.ValidateMetadata(String module, String metadataPath, String compilerMetadataPath, IEnumerable`1 referencedAssembliesFolders, IEnumerable`1 elements)
Build step: Metadata validation completed (10 ms).
Build step: X++ compilation, label generation and resource deployment started.
Build step: X++ compilation, label generation and resource deployment completed (670 ms).
Build step: Best practice check started.
Exception occured while performing operation Best practice checks. Exception details: BP Rule: [Exception occured while performing operation Best practice checks. Exception details]:System.ArgumentNullException: Value cannot be null.
Parameter name: referencedAssembliesFolders
at Microsoft.Dynamics.Framework.Tools.ILGeneratorAgent.MetadataProviderExtensions.AddReferenceProvider(IMetadataProvider provider, IEnumerable`1 referencedAssembliesFolders, IDiagnosticSink diagnostics, String modelModule, MetadataProviderFactory factory)
at Microsoft.Dynamics.Framework.Tools.ILGeneratorAgent.CompilationService.RunBestPracticeChecks(String module, String metadataPath, String compilerMetadataPath, IEnumerable`1 referencedAssembliesFolders, IEnumerable`1 elements, String modelName, Boolean isNormalizedCollectionNeeded)
Build step: Best practice check completed (9 ms).
Build completed (716 ms).
I attempted to disable running BP when building as a temporary workaround but that didn't work either. When BP is disabled i still can't compile. Here are the logs:
Build started 07/25/2019 06:40.
Build step: Metadata validation started.
Exception occured while performing operation Validate Metadata. Exception details: Path: []:System.ArgumentNullException: Value cannot be null.
Parameter name: source
at System.Linq.Enumerable.Contains[TSource](IEnumerable`1 source, TSource value, IEqualityComparer`1 comparer)
at Microsoft.Dynamics.Framework.Tools.ILGeneratorAgent.CompilationService.ValidateMetadata(String module, String metadataPath, String compilerMetadataPath, IEnumerable`1 referencedAssembliesFolders, IEnumerable`1 elements)
Build step: Metadata validation completed (8 ms).
Build step: X++ compilation, label generation and resource deployment started.
Build step: X++ compilation, label generation and resource deployment completed (381 ms).
Build completed (409 ms).
This issue can be caused if the update did not successfully update all components. This in turn can be caused if the default topology file is used for the update. The documentation by Microsoft is a bit confusing on this part of the update process (see issue 1137). Make sure to change the topology file according to section Collect topology configuration data in the documentation.
I also recommend to take a look at the d365fo.tools, which include the powershell function Invoke-D365SDPInstall that does a lot of the work in the updgrade process for you (including the update of the topology file).
Related
As part of an AWS CodePipeline in an AWS CodeBuild action I deploy resources created with the Serverless Framework to a "UAT" (user acceptance testing) stage.
The pipeline runs in its own tooling AWS account, first deploying cross-account into a separate "UAT" account, then deploying cross-account into a separate "Production" account.
The first deployment to "UAT" completes successfully, whereas the succeeding deployment to "Production" fails with the error ...
Serverless Error ----------------------------------------
An error occurred: <some name>LambdaFunction - Resource handler returned message: "Code uncompressed size is greater than max allowed size of 272629760. (Service: Lambda, Status Code: 400, Request ID: <some request id>, Extended Request ID: null)" (RequestToken: <some request token>, HandlerErrorCode: InvalidRequest).
Get Support --------------------------------------------
Docs: docs.serverless.com
Bugs: github.com/serverless/serverless/issues
Issues: forum.serverless.com
Your Environment Information ---------------------------
Operating System: linux
Node Version: 14.17.2
Framework Version: 2.68.0 (local)
Plugin Version: 5.5.1
SDK Version: 4.3.0
Components Version: 3.18.1
This started to happen, once I introduced the usage of a private Lambda Layer. The total size of all files seems way less than the maximum allowed size.
This question isn't so much about the actual error (there already exists a similar question).
I rather wonder why the behavior is inconsistent, varying with the deployment targets. Because the limits for the Lambda Function package size (including the usage of Lambda Layers) should be the same for all environments.
I've converted existing WCF application to web role by adding it with "Add web role project in solution". Convert menu doesn't offer me option to convert. Our application requires .NET 4.6.1
Application runs fine on full emulator. However deployment fails with two scenarios:
osFamily attribute set to "5" in Serviceconfiguration(no .NET 4.6.1 installation script required):
19:15:16 - Instance 0 of role Severa.API is restarting
Details: [11/28T17:15Z]Failed to load role entrypoint. System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
at System.Reflection.RuntimeModule.GetTypes(RuntimeModule module)
at System.Reflection.Assembly.GetTypes()
at Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.GetRoleEntryPoint(Assembly entryPointAssembly)
--- End of inner exception stack trace ---
at Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.GetRoleEntryPoint(Assembly entryPointAssembly)
at Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.CreateRoleEntryPoint(RoleType roleTypeEnum)
at Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.InitializeRoleInternal(RoleType roleTypeEnum) Last exit time: [2016/11/28, 17:15:06.916]. Last exit code: 0.
osFamily attribute set to "4" in Serviceconfiguration with .NET 4.6.1 installation:
The feature named NetFx451 that is required by the uploaded package is not available in the OS * chosen for the deployment.
I've used the .NET installation script in other projects with success. Also I have added WebRole.CS class to the project.
Is the issue here that the webrole is not WCF type meaning some setting etc. is missing?
We've managed to identify and fix the issue.
I've enabled Fusion logging and immediately got the missing information.
What would have saved a lot of time and point us to right direction would have been to understand that web role in CS consists of two processes: WAIISHost which runs RoleEntryPoint code in startup and good old W3WP for the Web application itself.
WAIIShost can't read Web.config and requires an empty Web.config file named after name of the project and redeployed successfully. I followed instructions from this article:
Post about the issue
So I have this webapp that I've been developing over the last half year or so. Recently I discovered that NancyFx had been upgraded to 0.16 on nuget and went to upgrade (from 0.12). Things went fine, or rather seemed to go fine, on my machine.However in on the CI machine, things went spectacularly wrong. I get the following StackTrace:
2013-02-25 14:28:51:145 - OtherApp - ERROR METHOD - Nancy.TinyIoc.TinyIoCContainer.ConstructType
2013-02-25 14:28:51:145 - OtherApp - ERROR MESSAGE - Unable to resolve type: Nancy.Routing.DefaultRouteResolver
2013-02-25 14:28:51:145 - at Nancy.TinyIoc.TinyIoCContainer.ConstructType(Type requestedType, Type implementationType, ConstructorInfo constructor, NamedParameterOverloads parameters, ResolveOptions options)
at Nancy.TinyIoc.TinyIoCContainer.SingletonFactory.GetObject(Type requestedType, TinyIoCContainer container, NamedParameterOverloads parameters, ResolveOptions options)
at Nancy.TinyIoc.TinyIoCContainer.ResolveInternal(TypeRegistration registration, NamedParameterOverloads parameters, ResolveOptions options)
at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
at System.Linq.Enumerable.<CastIterator>d__b1`1.MoveNext()
at Nancy.Diagnostics.DiagnosticsModuleCatalog.ConfigureContainer(IModuleKeyGenerator moduleKeyGenerator, IEnumerable`1 providers, IRootPathProvider rootPathProvider, IRequestTracing requestTracing, NancyInternalConfiguration configuration, DiagnosticsConfiguration diagnosticsConfiguration)
at Nancy.Diagnostics.DiagnosticsModuleCatalog..ctor(IModuleKeyGenerator keyGenerator, IEnumerable`1 providers, IRootPathProvider rootPathProvider, IRequestTracing requestTracing, NancyInternalConfiguration configuration, DiagnosticsConfiguration diagnosticsConfiguration)
at Nancy.Diagnostics.DiagnosticsHook.Enable(DiagnosticsConfiguration diagnosticsConfiguration, IPipelines pipelines, IEnumerable`1 providers, IRootPathProvider rootPathProvider, IEnumerable`1 serializers, IRequestTracing requestTracing, NancyInternalConfiguration configuration, IModelBinderLocator modelBinderLocator, IEnumerable`1 responseProcessors, ICultureService cultureService)
at Nancy.Diagnostics.DefaultDiagnostics.Initialize(IPipelines pipelines)
at Nancy.Bootstrapper.NancyBootstrapperBase`1.Initialise()
at Nancy.Hosting.Self.NancyHost..ctor(INancyBootstrapper bootstrapper, HostConfiguration configuration, Uri[] baseUris)
at Core.Jobs.HealthMonitorJob.Execute(IJobExecutionContext context)
at Quartz.Core.JobRunShell.Run()
Now I've tracked the issue down to a particular module which takes a lot of parameters which TinyIoC needs to handle creation for, and if I disable that module, Nancy starts fine, but of course without the necessary functionality. On my machine it works flawlessly. The only discernible difference between the two is that my machine is running Windows 7 while the CI is running Windows Server 2008 R2 Enterprise SP1. Does anyone else have any experience with anything like this happening? It's driving me mad.
The exception should have a tree of InnerException exceptions that should point out the specific type that there is an issue with.
I have my TFSService account hooked up to my Azure account, and am trying to publish the results of a TFSService build to my Azure account. Pretty sure I have my build definition set up properly - everything compiles just fine, which is great, but every time I try to deploy, I get the following error:
Exception Message: Could not find a part of the path 'C:\a\bin\_PublishedWebsites'. (type DirectoryNotFoundException)
Exception Stack Trace: at System.Activities.Statements.Throw.Execute(CodeActivityContext context)
at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager)
at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)
Anyone have any idea what could be wrong? For the record, manually publishing via right-clicking on my project in Visual Studio works fine (and is using the same publish profile) so not really sure what the deal is. I also am not 100% what info would be helpful for folks to use when debugging, so please just let me know what you guys would like to see and I'll update the question.
Thanks.
I fixed this by simply deleting the TFS integration in Azure and associated build configs in TFS, and then re-added.
This error occurs when the output location is set incorrectly.
The value for output location can be either "AsConfigured", "PerProject" or "SingleFolder".
http://msdn.microsoft.com/en-us/library/dd647547.aspx#output
For ex. If you have a single project with one configuration setup in the template the output location is set to SingleFolder.
Has anyone ever used Solrnet inside CLR Stored Procedures? I would really appreciate pointers to some good tutorials.
One problem I'm facing is that I can't find a way to include the SolrNet library as a reference to the VS (2008) Database (SQL Server) Project.
Update:
So it seems that when you have an SQL Server Project, and you want to add a reference to a library, it has to first exist in SQL Server itself, which makes sense. This is done by creating an assembly in SQL Server from the DLL itself with the following SQL:
CREATE ASSEMBLY SolrNet FROM 'C:\CLR_SP\SolrNet.dll'
WITH PERMISSION_SET = UNSAFE
(Note that UNSAFE might have some repercussions on the security of the database however it is ok for me for now)
However the SolrNet.dll requires other library dependencies such as Castle.Windsor.dll (which in itself requires System.Core.dll) and Ninject.dll. I found the required version of Castle.Windsor.dll (which is 2.5.1.0) and also System.Core.Dll (which was in the .Net folder of Windows), however I cannot find the required version of Ninject.dll (which should be 2.1.0.76). I have attempted to create assembly version 2.2 but, as expected, it did not do the job.
I searched for it on different repositories but could not find it. Does anyone know where I could find this version of DLL?
Update 2:
So after lots of searching over the net, I still didn't manage to find Ninject.dll v2.1.0.76. My next attempt was to use the next version of SolrNet (which is v0.4.0.2002). This version required Ninject.dll v2.2 which I had already found. So my current status is registering all other libraries in SQL Server which are dependencies of SolrNet.dll. I will leave this open to document my process just in case there will be someone having the same problem.
Update 3:
I have managed to register all required libraries (some of which I got from SolrNet source on GitHub). So now, SolrNet is registered as an assembly in SQL Server, and therefore I can reference it from the .NET SQL Server Project (for creating the CLR Stored Procedure). So I have written a very simple CLR SP which connects to SOLR and retrieves a piece of data. Code below:
[Microsoft.SqlServer.Server.SqlProcedure]
public static void PrintToday()
{
SqlPipe p;
p = SqlContext.Pipe;
p.Send("Helloooo");
// Open Solr instance
SolrNet.Startup.Init<ActiveProduct>("http://192.168.2.190:8983/solr");
// Get instance of ActiveProduct
ISolrOperations<ActiveProduct> operations = ActiveProduct.GetActiveProductSolrOperations();
// Prepare QueryOptions. This will be passed as a parameter into the query() method.
SolrNet.Commands.Parameters.QueryOptions qo = new QueryOptions();
qo.Start = 0;
qo.Rows = 20;
// Query Solr
SolrQueryResults<ActiveProduct> results = operations.Query(new SolrQueryByField("SearchDescription", "pants"), qo);
// Read results
String s = "Docs found: " + results.NumFound;
p.Send(s);
}
My next problem is that when I deploy and run the CLR SP, an error is popping stating that Solr is already registered in container. The exact output that I see in SQL Server Management Studio is the following:
Helloooo
Msg 6522, Level 16, State 1, Procedure PrintToday, Line 0
A .NET Framework error occurred during execution of user defined routine or aggregate 'PrintToday':
System.ApplicationException: Key 'SolrNet.Impl.SolrConnection.CLRStoredProcedures2.ActiveProduct.SolrNet.Impl.SolrConnection' already registered in container
System.ApplicationException:
at SolrNet.Utils.Container.Register(String key, Type serviceType, Converter`2 factory)
at SolrNet.Utils.Container.Register[T](String key, Converter`2 factory)
at SolrNet.Startup.Init[T](ISolrConnection connection)
at SolrNet.Startup.Init[T](String serverURL)
at StoredProcedures.PrintToday()
PrintToday is the name of the CLR StoredProcedure
CLRStoredProcedures2 is the name of the .NET SQL Server project and default namespace in VS 2008
ActiveProduct is the name of the document in Solr, and the cs class with Solr annotations
As can be seen from the output, the first Pipe.send("Hellooo") is doing its job therefore the SP works fine until there.
When I searched for the above error, I found out that it will show when one tries to register Solr instance twice in the same application. Now I don't see where I am registering the instance twice. Am I missing something here?
Note that the above cs function worked fine when executed in a cs console application developed on my machine. Another detail which might be important is that the SOLR Server is being hosted on my machine which is on the same network of my SQL Server 2005.
Update 4:
For starters, the error I mentioned above (in update 3) does not fire when the SP is executed the 1st time just after deployment (let's assume that the 1st time works for now since I have another error which I'm currently working on fixing), the error fires when the SP is executed again afterwards. So it seems that whatever SolrNet.Startup.Init<ActiveProduct>("http://192.168.2.190:8983/solr"); is doing (creating some sort of session that has to do with a container I think) when called from the SP it is not releasing the "session" therefore the 2nd time (and each time afterwards) the SP is executed, the error is fired. Is there a way to sort of stop the session or releasing from the container. What I can do as a workaround is to try - catch the SolrNet.Startup.Init part, however this is not clean.
Thanks.
I'll try to summarize the steps / requirements with explanations whenever possible:
For some reason SQL Server seems to trigger the "hidden" dependencies of the merged SolrNet. Usually you can just use the merged SolrNet (which includes all integration modules) and if you ignore the integration classes the dependencies won't trigger. But in this case the unmerged SolrNet is necessary.
SolrNet does HTTP requests to the Solr server, so the DLL must be registered with UNSAFE permissions in SQL-CLR.
SolrNet Initialization (Startup.Init) must happen only once per application, but you don't have a 'root' context in SQL-CLR to place this initialization. A workaround is to use a singleton or a Lazy type. SQL-CLR doesn't run .NET 4 yet, but you can backport the Lazy type or use FSharp.Core.dll's implementation (I blogged about this some time ago)