I am wanting to generate all of our application documentation using VSDocman and put them on Sharepoint. The act of uploading the finished documentation to Sharepoint isn't an issue and can be done fairly easily. The issue I have however is that VSDocman will not let me embed images in to the documentation unless I have the External Files Folder property set in its settings.
I want to set this property to be a child-directory on the sharepoint server where I place the actual generated documentation. So if my path is http://sharepointsite/documents/project1/docs, I'd want to place the directory in http://sharepointsite/docuemnts/project1/docs/images/
I'm not sure how to do that with Sharepoint. I have not been able to find any documentation online on how to basically connect to that sharepoint directory using a network drive or something that i can point VSDocman to. Anyone have any experience with trying to map to a sharepoint drive, without using the sharepoint workspace syncing? I need to basically have a filepath to the directory for VSDocman to use explicitly.
Thanks.
I was able to resolve this by mapping as a network drive using
\\sharepointsite\shared documents\project1\docs\images
In windows explorer. Once I figured out I could map to the drive, I just paste the same url in to VSDocman and attach the images that I needed. Worked like a charm.
Related
I have created a Google drive folder which is shared with others. I am trying to take regular backups of whatever docs are created in that folder using xcopy. While uploaded files are getting backed up, created files such as docs etc., are not. Command line throws the error "target folder does not support symbolic links".
I tried changing privileges in windows administrative tools to include other users to be able to create symbolic links but still it didn't work. Help please!!
I am trying to start a workflow in my SharePoint 2013 provider hosted app.
The class I'm looking for is WorkflowServicesManager, however the dll Microsoft.SharePoint.WorkflowServicesBase.dll is not in the location I would expect.
Where can I get this dll from?
thanks
You can make a reference to file directly using it's location for Microsoft.SharePoint.WorkflowServicesBase:
%Windows%\Microsoft.NET\assembly\GAC_MSIL\Microsoft.SharePoint.WorkflowServicesBase\v4.0_15.0.0.0__71e9bce111e9429c\Microsoft.SharePoint.WorkflowServicesBase.dll
I aslo wasn't able to get it usual way and had to reference file manually
I'm deploying a .NET application with VS2010. My application creates .txt file in the logs folder in the same directory with .exe:
app.exe
add.exe.config
logs (folder)
I used setup project to create a MSI installer. When I installed in the client machine C: drive or any drives I have no problem to create the .txt file, but when I installed in C:\Program File\myAppFolder or C:\Program File(x86)\myAppFolder I cannot to create the .txt file.
It is a poor design to write to install location for your application. It is better to write to the ApplicationDataFolder. The ApplicationDataFolder is under the user profile and the application will have access to write there when run as that user. #Ken White provided a very good pointer to an existing StackOverflow answer about this.
If this is a legacy application that must write to that folder, then you'll need to modify the permissions on the log folder such that all users can write to the folder. This is possible to do with the Windows Installer (aka: MSI) but I'm not sure that the Visual Studio setup projects expose it. The WiX toolset definitely supports doing such things.
An old post but I needed to do similar recently so I guess it is still valid! While I don't advocate bad design, in the real world sometimes we have to bend to requirement.
Writing to the application folder is possibly under Win7 and it is possible to set this up via an installer class in an MSI created by VS2010. You just need to give a relevant group (suggest either the "Users" group, or if you want to give more control over who gets what, supply a selection screen) Write-Data access.
Using DirectoryInfo on a path you can then get the security data from GetAccessControl.
When you have your Group known, get the SID for the group and AddAccessRule also supplying the required ControlType value.
Then set the access control on the DirectoryInfo object (SetAccessControl) using the security data object.
You can get the SID from the Groups principal object if you do a search with PrincipalSearcher.
Hope this helps
paul
This generally all depends on:
Whether your app requires to be run as administrator for other reasons and..
Whether your app is provided for limited users.
If the app requires elevation for a bunch of other reasons (and not just updating files in restricted locations) then the normal way is to have an elevation manifest embedded in your app. This isn't a good thing from the security point of view, but if you absolutely need admin privilege then this is the way to do it.
If the only operation requiring elevation is updating/creating data in the Program Files folder then don't put the file there. Every case of this that I've seen has been lazy programming where the code just refers to the file name and consequently it goes in the Program Files folder (more accurately in the same folder that the app runs in). The cure for this is to put the data file in the correct location (such as User's Application Data folder). As Rob Mensching says, you should alter the permissions on the install folder only if this is a legacy app that you cannot change.
I just want to be able to remove some specific files in my temporary internet files folder (for Internet Explorer), however I know that this is a special folder, and it doesn't seem to be straight-forward. Do I need to use the Shell object and reference WinINET? Was planning on doing this in C# or VB. Something simple. Any input is much appreciated.
Thanks
MSCRM 4.0
Problem:
I'm currently storing xml files in the ISV directory along with my web applications. From a plugin (or potentially a seperate app), I need to find an easy way to navigate to the ISV directory to read these xml files. This routine will be called extremely often, so processing minimization should be a strong consideration.
Potential solutions:
Registry: There is a registry key called 'WebSitePath' with the data 'C:\Inetpub\wwwroot\CRM'. Could potentially use this to build the path. (Will this be the same on all systems/installations?)
IIS directory data: Looping through the DirectoryEntries of path '"IIS://localhost/W3SVC"' I could obtain the the web application where description is equal to "Microsoft Dynamics CRM". (Will this be the same on all systems/installations?)
Webservice: Create one to read and return the data contained in these xml files The webservice would have easy access to its executing directory.
Database: Store the data of these files in the database.
Help:
Can anyone suggest a simpler solution to obtaining and reading a file from the ISV directory? If not, which of the above solutions would be the quickest to process?
Thanks for any and all contributions.
If you manage your deployment, I would first try to access the file at the location that you think the file can be found (like an hint). If you can't find it, I would try to retrieve the ISV folder location using the registry.
If you are not controlling the deployment, using a file in the ISV folder is not a good solution, because CRM can be deployed using different roles, and the ISV folder is not necessarily on the same server, so I would rely on a external database.