How load custom .net dll with accoreconsole.exe in Design Automation with all AutoCAD DLL's - autodesk-forge

I have created a AutoCAD custom .net dll for the desktop version which had some operation.
Adding multiple empty drawing documents.
Opening the existing drawing document and copying the required blocks in the newly created drawing document.
Performing some operation on them, discarding all the unnecessary drawing documents and saving one of them as an output drawing document.
I had a query regarding opening the existing document and adding the empty document using Design Automation API but I couldn't achieve it with Design Automation.
As I explored I found that only AcCoreMgd.dll and AcDbMgd.dl are allowed with accoreconsole.exe.
Load custom .net dll inside accoreconsole.exe
DLL's used by AutoCAD custom .net project for desktop version are (AcCoreMgd.dll,AcCui.dll,AcDbMgd.dll,AcMgd.dll,AcTcMgd.dll,AdUIMgd.dll)
I wanted to use all the above DLL's with Design Automation for AutoCAD.
Will you please let us know how we can use desktop versions like support in Design Automation for AutoCAD?

It is not possible to add other modules when working with Design Automation or AccCoreConsole. Please note AcCoreConsole is a Headless part of AutoCAD in other words no UI libraries are permitted. Following are the libaries that a crx app should bind.
Where XX - module version of AutoCAD release for more details
If you are developing a .NET module, you need to use following Nuget
ac1stXX.lib
acdbXX.lib
acdbmgd.lib
AcDbPointCloudObj.lib
acgeXX.lib
acgiapi.lib
acismobjXX.lib
AcMPolygonObjXX.lib
AcSceneOE.lib
axdb.lib
rxapi.lib
acbrXX.lib
acgexXX.lib
AdImaging.lib
AdIntImgServices.lib
AecModeler.lib
AsdkHlrApiXX.lib
acapp_crx.lib
AcCamera.lib
accore.lib
AcFdEval.lib
AcPublish_crx.lib
Why do you need to open mutilple documents ?, you can insert multiple blocks from different drawings in to Host drawing. Make modifications, save and send to your Server.

Related

Deleting PrecompiledViews.dll from ASP.Net Core 2 API

In .NET Core 2 Web API app, Publish to folder feature in MS VS 2017 produce:
<ProjectAssembly>.PrecompiledViews.dll
<ProjectAssembly>.PrecompiledViews.pdb
Offical docs says that PrecompiledViews related to precompiling Razor Views, but my API doesn't contain any views or static files, just REST endpoints that return json.
Using .Net reflector I found the PrecompiledViews.dll empty.
So I deleted PrecompiledViews.dll and tested my API and it seems to work fine without any warnings or exceptions.
Is it safe to delete PrecompiledViews.dll and pdp if the API not using any razor views? If yes, Is there option in VS 2017 to stop publishing unused PrecompiledViews?
You are right, the precompile step always emits an assembly and doesn't check if there are actually views. You can disable the precompilation step by putting this into your csproj file:
<PropertyGroup>
<MvcRazorCompileOnPublish>false</MvcRazorCompileOnPublish>
</PropertyGroup>
This will then activate the normal copilation context preservation (refs subfolder). To deactivate this as well, add
<PreserveCompilationContext>false</PreserveCompilationContext>
to the property group.

Error accessing WinRT sensors in C++ desktop application

I am trying to access the WinRT sensors from a Win32 desktop application using C++/CX as mentioned here: https://software.intel.com/en-us/articles/using-winrt-apis-from-desktop-applications
When I include the C++/CX header file it causes an error when building the Win32 project.
Exact error text: "error C1190: managed targeted code requires a '/clr' option."
Since I am not using /clr code at all, this is a confusing error.
Any suggestions? Please educate me if there is a better way to do this.
The error you are getting is because you are compiling some files without /ZW option for compiler. Since you are able compile at least some files with WinRT extensions, but not others, your project configuration is inconsistent.
The option /ZW (enable WinRT extensions) has to be configured on the level of project (and not on the level of individual files). There are two ways to ensure your settings are consistent. First method is through UI in Visual Studio -- you have to go through all platforms/configurations on the project and ensure /ZW is enabled, then got through all indivudual .cpp files, and ensure they don't override project level settings. This is tedious and error prone. The easier method is to open .vcxproj in notepad and do the following:
Add this section at the beginnig of the file, under root Project node:
<ItemDefinitionGroup>
<ClCompile>
<CompileAsWinRT>true</CompileAsWinRT>
</ClCompile>
</ItemDefinitionGroup>
Search and remove any other places where <CompileAsWinRT> is defined.

How to package a Windows Runtime component for distribution?

I have built a WinRT component (.winmd) for use by both JavaScript and XAML Windows Store apps. When including and referencing the loose .winmd file output in a JavaScript client, I see this build warning:
Microsoft.AppXPackage.Targets(808,9): warning APPX1707: No implementation file was provided for the .winmd file 'myRuntimeComponent.winmd'. To generate registration information in the app manifest, specify the 'Implementation' metadata on the .winmd reference item in the project file.
I can't find any documentation on this error or how to include implementation metadata.
When running the JavaScript client, this exception is thrown when a class method exported from the .winmd is called:
0x80040154 - JavaScript runtime error: Class not registered
Note that I am referencing the loose .winmd file in the client application project, rather than referencing the Visual Studio project that builds the .winmd. My use case is distributing the .winmd output, not the full source for the .winmd component - source distribution is not an option.
Also note that when the Windows Runtime component is referenced as a project reference, the JavaScript client builds and runs correctly. The C# XAML client runs correctly with either a project reference or a reference to the loose .winmd.
It seems as if some registration information is not being generated in the client application build when a loose .winmd is referenced.
How can I build and distribute a loose Windows Runtime component for use by both JavaScript and managed clients?
A WinRT component built with C# or VB produces a .winmd that contains both metadata and implementation. A component built with C++ provides separate .winmd and .dll files, and the DLL is what contains the details to register the component.
Apparently, as the warning indicates, you need to edit the project file with something like the following to point to the DLL:
<Reference Include="component">
<HintPath>component.winmd</HintPath>
<IsWinMDFile>true</IsWinMDFile>
<Implementation>component.dll</Implementation>
</Reference>
Alternatively you might want to look into Extension SDKs. See the below link for how to package your component as an easy to consume Extension SDK in VS:
http://msdn.microsoft.com/en-us/library/jj127119.aspx

Building Windows Store app programmatically

We have a requirement of creating several Windows 8 apps for tablets. There is a common solution and news apps are created by passing different resource to the same code.
For Mobile it was a cakewalk - Used the Microsoft.Build.Evaluation.Project class to get the xap file.
But for Surface, building from code does not give the direct appx output, while building using MSBuild gives appx as the output.
I tried several methods to avoid calling MSBuild from C#(by creating a Command Process) like creating a zip file - myapp.appx - and then signing it using this c++ code. It didn't workout because of an extern reference and I gave up.
Then I tried to use SignTool.exe by creating a Command Process in C#. That too failed.
So, I am wondering if there is any way to build an appx directly from C# without MSBuild.
The reason why I am trying to avoid MSBuild is to get a status from the build process, which Microsoft.Build.Evaluation.Project.Build() provides.
First try adding a pfx key to your project and then try the build via Microsoft.Build.Evaluation.Project.Build() again. The pfx is required from what I read:
See Candy's answer here:
MSBuild target to create the .appx package
So then the trick would be to use SignTool to get the pfx in the first place and update the project with that pfx, but first see if the above works.

How do I disable code generation in my test plugin?

I have a couple of test files written in my DSL in my tests plugin/project. Most of the tests use inline multi-line strings and Xtend but in four cases, I need to test code which does some magic with URLs and the classpath, so I really need resources in the classpath for that.
Since loading the resources only works when the extension is correct, I can't give the files a fake extension.
Now my problem: My DSL also has a code generator. This means that eventually, I end up with a couple of generated files in places where I can't have them (they don't compile, for example, and one even contains an error to test error handling when information is split across several files).
I can't disable the Xtext nature because the tests project uses Xtend so for these files, I do need code generation.
Since the generator runs inside Eclipse (I have the DSL plugins installed for other projects), there is no way to override the code generator in Guice.
How can I disable the code generator in this case?
There is a simple way to achieve this:
Open the properties of your project
Expand the entry for your DSL
Select "Compiler"
Select "Enable project specific settings"
Disable/deselect "Compiler is activated" under "General"
If you don't have a properties entry for your DSL:
Add this fragment to your .mwe2 workflow file:
fragment = generator.GeneratorFragment {}
Regenerate your projects
Merge the new code from plugin.xml_gen into plugin.xml both in the base and the UI plugins.
The interesting parts are the two extension points org.eclipse.ui.preferencePages and org.eclipse.ui.propertyPages