I would like to know where the ProductCode (GUID) of an autoloading DLL for AutoCAD is coming from. I have developed a plugin in DLL that has some commands for AutoCAD. I follow a "known good" example program and create a bundle for my plugin. The DLL failed to autoload for some reason. I am wondering may be the ProductCode (GUID) that I have entered in PackageContents.xml is wrong. That's why I want to find out the correct way to find a ProductCode.
Based on the example program, I am sure that the ProductCode is NOT the GUID stated in section in the Visual Studio project file. And I am also sure that the ProductCode is NOT the GUID stored in AssemblyInfo.cs file either.
Should I use the GUID inside the DLL file? But I have no way to tell which GUID is embedded inside the DLL file.
As of now, I simply use the GUID generated using Visual Studio --> Tools --> Create GUID. But I don't know if this is the right GUID to use. Or does this really matter which GUID to use as long as it is unique?
Please help. Thanks.
Jay Chan
When you create a new PackageContents.xml file for your bundle, you have to create a new GUID (menu Tools > Create a Guid) as ProductCode and an another one as UpgradeCode, then, for each new version of your application, you should create a new GUID for the ProductCode but never change the UpgradeCode one.
If you also build an installer (Windows Installer), a good practice is to set the same GUIDs for ProductCode and UpgradeCode in the PackageContents as those generated by VisualStudio for the installer.
More details about Autoloader here:
http://adndevblog.typepad.com/autocad/2013/01/autodesk-autoloader-white-paper.html
Related
I am unable to find the Firebase library for Google Apps Script.
I followed the following instruction:
https://sites.google.com/site/scriptsexamples/new-connectors-to-google-services/firebase
The in this article mentioned project key / script id can not be found when trying to add the library in my new project.
The Look Up renders:
Unable to look up library. Check the ID and access permissions and try again.
Am I missing something? Am I doing something wrong?
Use the Script ID
as opposed to the Project Key
For this library it's:
1hguuh4Zx72XVC1Zldm_vTtcUUKUA6iBUOoGnJUWLfqDWx5WlOJHqYkrt
New editor vs Legacy
With the move to the new editor, using Project Keys no longer work.
See the different instructions for the New vs Legacy Editor in the docs:
https://developers.google.com/apps-script/guides/libraries
Adding a library if you only have the Project Key
If you can't find the ID for a particular script, while the Legacy editor is still available you can switch to the Legacy editor to add it with a Project Key, and then switch back to the new editor.
Finding the Script ID if you only have the Project Key
Maybe you want to get the ID for later reference. To get this, once you have it added, you can press the "three dots" button next to the library name and select "Open in new tab". Once you have it open, you can get the ID from the URL.
I came here because I tried to use a deployment id for a script library.
The fix was to use the project id which I found under project settings.
The answer from 'iansedano' is correct. I just want to add that a to get the 'script id' it's easier to just go to the settings and copy it from there:
Is there a way where the database references in a SQL Server Database project (Dacpac) can be derived at run time?
We're building a product which uses Dacpac to deploy database objects.
Our product implementation teams also use Dacpac projects by adding database reference to the product Dacpac file and then adding their own additional objects to the project.
The problem we're facing is - every time the implementation needs to point to a newer product release version, the parent dacpac references in the implementation dacpac have to be changed manually to refer to the new file path of the new product dacpac (in the newer release). We've mutiple implementation teams and multiple database projects in each implementation.
Is there any way the database references (*.dacpac) in a database project can be derived at run time using a variable or parameter or something of that sort?
My understanding of your question is as follows:
You have a SSDT database project (see example image below), that has a database reference (similar to #1 below) with stored procedures and other db objects that access the reference database (similar to file #2 and code #3). You've 'built' the solution resulting in a DACPac and now you want to take this DACPac and reference other databases at deploy-time. Hopefully I understood your question correctly.
If so, then you can use the Publish Profiles feature to achieve this (similar to #4 below).
The code for this can be seen in my notes from my SSDT talk github project.
If you look specifically at the demo04 solution file, you will see that I have a DEV_MJE.deploy.ps1 PowerShell file and a DEV_MJE2.deploy.ps1 file. These scripts run MSBuild to build the DACPac and then use SqlPackage to publish DEV_MJE.publish.xml or DEV_MJE2.publish.xml respectively. Note, if you run this example on your machine, you'll need to add MSBuild.exe and SqlPackage.exe to your path, as well as modifying the TargetConnectionString in the xml files to an existing development database.
As an example of how this works...When I use the Publish Profile DEV_MJE.publish.xml, the resulting GetDataFromAnotherTable.sql file contains:
SELECT [SomeData] FROM [AnotherDb_MJE].[dbo].[AnotherTable]
Whereas when I use DEV_MJE2.publish.xml the resulting GetDataFromAnotherTable.sql file contains:
SELECT [SomeData] FROM [AnotherDb_MJE2].[dbo].[AnotherTable]
Notice the database reference in the second has changed to AnotherDb_MJE2.
For a good description of how Publish Profiles relate to DACPacs and SSDT Database Projects, see this web page. It also contains information on alternative ways to deploy beyond SqlPackage.exe.
Something else to consider
Note, that using file paths to version control a DACPac is not really the best practice. Consider the DACPac artifact as similar to a .Net DLL. It is the biproduct of a build.
As such, a better approach is to use NuGet and tools like Octopus Deploy to store, track, and deploy DACPacs. See the stackoverflow answer for a good description of how this works.
Hope that this helps,
Michael
Thanks for the followup comment, I think what you are trying to do is when you write and deploy your code be able to use different dacpacs depending on the project?
Each implementation team might have a different version of the shared dacpac deployed so you can't just put the files in a shared location and call the dacpac "Product_Latest.dacpac" or something, so everyone always gets the latest version.
".sqlproj" files are standard msbuild scripts and references can be managed using msbuild properties so you can technically change the reference at runtime. If you edit your .sqlproj file and add a property in the first <PropertyGroup> tag, I used:
<ProdDacpacVersion Condition="'$(ProdDacpacVersion)' == ''">v1</ProdDacpacVersion>
v1 is the unique name for the version folder - you just need something to identify the dacpac you want.
I put the property just after TargetDatabaseSet and IncludeCompositeObjects.
If you then find the reference to the dacpac and instead of
<ArtifactReference Include="..\..\..\..\..\Desktop\prod\v1\Database2.dacpac">
<HintPath>..\..\..\..\..\Desktop\prod\v1\Database2.dacpac</HintPath>
<SuppressMissingDependenciesErrors>False</SuppressMissingDependenciesErrors>
</ArtifactReference>
Use the property from above:
<ArtifactReference Include="..\..\..\..\..\Desktop\prod\$(ProdDacpacVersion)\Database2.dacpac">
<HintPath>..\..\..\..\..\Desktop\prod\$(ProdDacpacVersion)\Database2.dacpac</HintPath>
<SuppressMissingDependenciesErrors>False</SuppressMissingDependenciesErrors>
</ArtifactReference>
Then the reference will use the property to get the path of the dacpac. There are a few ways you can set the property, you could edit the .sqlproj file when you want to take a new version of read the property from a file or environment variable or something (i'll leave the msbuild fun to you!).
I would, as a standard, everytime the reference was changed either reload the project or restart visual studio - it won't take long and it will save lots of cursing :)
When you deploy the dacpac's, the deploy looks in the same folder for references first so just make sure you copy the right one into the bin folder when you deploy.
How to create GUIDs in Visual Studio 2013? I had an add in that worked well in VS2012 but it does not work in VS2013. I found this Create GUID in VS2012 and this How to convert VS2012 add ins to VS2013 Packages but could not make it work (add ins are not my forte - I simply edit SQL scripts). Is there an easy way to get back this functionality?
If you're using ReSharper (highly recommended), you can create new GUIDs everywhere by typing nguid and pressing Tab.
Actually, uou can just use guidgen.exe which should get installed with VS.
Using menu TOOLS -> External Tools... add:
%Installation Path%\Microsoft Visual Studio 12.0\Common7\Tools\guidgen.exe
e.g.
C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\guidgen.exe
Give the title of ‘Create GUID’ and it is there just as it was in VS2010.
The best tool / add-in for this is:
http://visualstudiogallery.msdn.microsoft.com/22795583-5cc9-4681-af8e-6084f3441655
I was also wondering how I should do this. I saw the following example: Inserting a Guid for VS 2012. For VS2013 you have to install the SDK. Once you have done that you will see the template project items for packages and also for addins when you go to add a new project.
Despite the documentation saying that addins were deprecated in VS2013 they do appear to work (I am using VS2013 Ulitmate v 12.0.21005.1 REL). You can follow the instructions in the previous article.
I also created a package which was relatively straight forward too. Using How to: Convert an Addin to a VS Package I was able to create the package.
As in the article I added the following using statements:
using EnvDTE;
using EnvDTE80;
I then changed the MenuItemCallback method to the following:
private void MenuItemCallback(object sender, EventArgs e)
{
DTE2 dte = (DTE2)GetService(typeof(DTE));
if (dte.ActiveDocument != null)
{
TextSelection objSel = (EnvDTE.TextSelection)(dte.ActiveDocument.Selection);
objSel.Insert(Guid.NewGuid().ToString());
}
}
After building the project I went to the bin\Debug folder and started the vsix file (GuidPackage.vsix in my case). This installed the package for use in the IDE.
I now have a menu item to insert guids into my code and am able to create a shortcut key stroke for it in the usual way.
Just use PowerShell from VS Package Manage Console:
Switch to Package Manager Console (or you can open PowerShell cmd).
Execute [guid]::NewGuid().
Result:
Guid
----
61dabfd8-9151-46f5-8d92-72306044d844
I prefer to use this solution:
_TUCHAR *guidStr = 0x00;
GUID *pguid = 0x00;
pguid = new GUID;
CoCreateGuid(pguid);
// Convert the GUID to a string UuidToString(pguid, &guidStr);
delete pguid;
One other tool that I came by was this extension. Works pretty good
"Insert new GUID" (Shift+Alt+G): Inserts a new GUID at the current position.
"Insert last GUID" (Ctrl+Shift+Alt+G): Re-inserts the last new GUID at the current position.
We have migrated from 5.3 version to Tridion 2011 SP1
In compound templating setup, we have created one project called "CommonFunctions" which contains functions which are used frequently throughout the website.
This cs file is built to tridion content manager and we are trying to reference it in other project using
Add Exixting Item > CommonFunctions.cs > Add as link
But when i try to build my project(in which commonFunctions cs file is referenced) it gives me following error:
Cannot generate a template with name CommonFunctions since a generated template created for another assembly template is already present.
Can anyone help in this?
Thanks and Regards
Reason is very straight forward, if you go with the error message. You are trying to create two TBB's with same name(CommonFunctions).
I am suggesting you either to alter your already existing TBB or rename the new one.
Does your CommonFunctions class implement ITemplate? If so then this is why you're seeing the error. Doing so means that, when uploaded, Tridion will try to create a TBB for it, giving you the situation where you have a naming conflict. What's in the class? It should either be help functions or a "template" (TBB), but not both. At least, not if you want to reuse your existing functionality in this way.
You have several options as I see it. The first would be to upload the new assembly to a different folder than the one that is currently in use. The second would be to copy the class to your new project and rename it. The third would be to separate your helper functions from the TBB class in to one that doesn't implement ITemplate, which you could then reference as you're currently trying from your new project.
I'm writing a desktop app which needs a simple persistence layer - I found out about SubSonic and it's capability to work with SQLite. However I need to keep the database file in user's AppData folder and don't know how to put such value into app.config - I don't want to use absolute paths.
Can app.config somehow access enviroment variables or reference application data folder?
For subsonic v2.x I would ignore the app.config connection string and just set it at runtime before working with the database. The provider name stays the same of course.
string dbPath = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData), #"MyApplication\Northwind.db3");
DataService.Providers["Northwind"].DefaultConnectionString =
String.Format(#"Data Source={0};Version=3;New=False;Connection Timeout=3", dbPath);
There's no way to specify the AppData folder in the app.config for a connections string.
But what you could do is write the value to the config file either during install or when the application is first run.
The "framework way" of finding appdata is to use Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
This will find the correct appdata path regardless of platform.
There are several ways if you are using ASP.NET , in either language
Server.MapPath("~") will return the root of the application as a full path name then you can just add "/app_data" to it to get you're full path.
Alternatively inspect the HttpContext.Current.Request and HttpContext.Current.Application
there are numerous ( and much better then the one I just mentioned ) properties that will provide you with the same folder - being the root of the application as s full path.
Note that these should all work even if you have the application as a virtual folder and a regular folder with an application configures in IIS on that folder
However this is only possible at runtime , so it can't really be mentioned in the app.config. you could try using relaltive paths from where the app.config is resident IE "../App_Data" or "/App_data" but I'm not sure of you're exact requirements.
Good luck